From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 05:35:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C66016A41F for ; Sun, 6 Nov 2005 05:35:23 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 498B743D45 for ; Sun, 6 Nov 2005 05:35:23 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EYdBa-000EyU-ET for freebsd-current@freebsd.org; Sun, 06 Nov 2005 05:35:23 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EYckj-0007ET-5X for freebsd-current@freebsd.org; Sat, 05 Nov 2005 19:07:37 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17261.36760.762443.538898@roam.psg.com> Date: Sat, 5 Nov 2005 19:07:36 -1000 To: FreeBSD Current Subject: azureus -> eclipse -> cairo problems persist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 05:35:23 -0000 fresh cvsup, now post 6 release new world and kernel upgraded gnome to 2.12 (which removed azureus) portupgrade -N net/azureus it makes cairo, but eclipse can't find the bit of cairo it wants Making install in src test -z "/usr/local/lib" || /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d "/usr/local/lib" /bin/sh /usr/ports/graphics/cairo/work/gnome-libtool --mode=install /usr/bin/install -c -o root -g wheel 'libcairo.la' '/usr/local/lib/libcairo.la' /usr/bin/install -c -o root -g wheel .libs/libcairo.so.2 /usr/local/lib/libcairo.so.2 (cd /usr/local/lib && { ln -s -f libcairo.so.2 libcairo.so || { rm -f libcairo.so && ln -s libcairo.so.2 libcairo.so; }; }) (cd /usr/local/lib && { ln -s -f libcairo.so.2 libcairo.so || { rm -f libcairo.so && ln -s libcairo.so.2 libcairo.so; }; }) /usr/bin/install -c -o root -g wheel .libs/libcairo.a /usr/local/lib/libcairo.a ranlib /usr/local/lib/libcairo.a chmod 644 /usr/local/lib/libcairo.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- test -z "/usr/local/include/cairo" || /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d "/usr/local/include/cairo" install -o root -g wheel -m 444 'cairo.h' '/usr/local/include/cairo/cairo.h' install -o root -g wheel -m 444 'cairo-features.h' '/usr/local/include/cairo/cairo-features.h' install -o root -g wheel -m 444 'cairo-ft.h' '/usr/local/include/cairo/cairo-ft.h' install -o root -g wheel -m 444 'cairo-pdf.h' '/usr/local/include/cairo/cairo-pdf.h' install -o root -g wheel -m 444 'cairo-ps.h' '/usr/local/include/cairo/cairo-ps.h' install -o root -g wheel -m 444 'cairo-xlib.h' '/usr/local/include/cairo/cairo-xlib.h' install -o root -g wheel -m 444 'cairo-xlib-xrender.h' '/usr/local/include/cairo/cairo-xlib-xrender.h' Making install in doc Making install in public installfiles=`echo ./html/*`; if test "$installfiles" = './html/*'; then echo '-- Nothing to install' ; else /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d /usr/local/share/doc/cairo/cairo; for i in $installfiles; do echo '-- Installing '$i ; install -o root -g wheel -m 444 $i /usr/local/share/doc/cairo/cairo; done; echo '-- Installing ./html/index.sgml' ; install -o root -g wheel -m 444 ./html/index.sgml /usr/local/share/doc/cairo/cairo || :; fi -- Installing ./html/Drawing.html -- Installing ./html/Fonts.html -- Installing ./html/Support.html -- Installing ./html/Surfaces.html -- Installing ./html/bindings-errors.html -- Installing ./html/bindings-fonts.html -- Installing ./html/bindings-memory.html -- Installing ./html/bindings-overloading.html -- Installing ./html/bindings-path.html -- Installing ./html/bindings-patterns.html -- Installing ./html/bindings-return-values.html -- Installing ./html/bindings-streams.html -- Installing ./html/bindings-surfaces.html -- Installing ./html/cairo-Error-handling.html -- Installing ./html/cairo-Font-Options.html -- Installing ./html/cairo-FreeType-Fonts.html -- Installing ./html/cairo-Glitz-Surfaces.html -- Installing ./html/cairo-Image-Surfaces.html -- Installing ./html/cairo-PDF-Surfaces.html -- Installing ./html/cairo-PNG-Support.html -- Installing ./html/cairo-Paths.html -- Installing ./html/cairo-Patterns.html -- Installing ./html/cairo-PostScript-Surfaces.html -- Installing ./html/cairo-Scaled-Fonts.html -- Installing ./html/cairo-Text.html -- Installing ./html/cairo-Transformations.html -- Installing ./html/cairo-Types.html -- Installing ./html/cairo-Version-Information.html -- Installing ./html/cairo-Win32-Fonts.html -- Installing ./html/cairo-Win32-Surfaces.html -- Installing ./html/cairo-XLib-Surfaces.html -- Installing ./html/cairo-cairo-font-face-t.html -- Installing ./html/cairo-cairo-matrix-t.html -- Installing ./html/cairo-cairo-surface-t.html -- Installing ./html/cairo-cairo-t.html -- Installing ./html/cairo.devhelp -- Installing ./html/home.png -- Installing ./html/index.html -- Installing ./html/index.sgml -- Installing ./html/ix01.html -- Installing ./html/language-bindings.html -- Installing ./html/left.png -- Installing ./html/pt01.html -- Installing ./html/pt02.html -- Installing ./html/right.png -- Installing ./html/style.css -- Installing ./html/up.png -- Installing ./html/index.sgml Making install in test test -z "/usr/local/libdata/pkgconfig" || /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d "/usr/local/libdata/pkgconfig" install -o root -g wheel -m 444 'cairo.pc' '/usr/local/libdata/pkgconfig/cairo.pc' ===> Running ldconfig /sbin/ldconfig -m /usr/local/lib ===> Registering installation for cairo-1.0.2 ===> Returning to build of eclipse-3.1.1_1 Error: shared library "cairo.1" does not exist *** Error code 1 Stop in /usr/ports/java/eclipse. *** Error code 1 Stop in /usr/ports/net/azureus. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade92733.0 make JAVA_EXTRACT=yes ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! net/azureus (dependent libraries) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 06:06:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A66B716A41F for ; Sun, 6 Nov 2005 06:06:40 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from centrmmtao01.cox.net (centrmmtao01.cox.net [70.168.83.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23CE843D45 for ; Sun, 6 Nov 2005 06:06:40 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by centrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051106060612.UBYV5336.centrmmtao01.cox.net@mezz.mezzweb.com>; Sun, 6 Nov 2005 01:06:12 -0500 To: "Randy Bush" References: <17261.36760.762443.538898@roam.psg.com> Message-ID: Date: Sun, 06 Nov 2005 00:07:13 -0600 From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <17261.36760.762443.538898@roam.psg.com> User-Agent: Opera M2/8.50 (Linux, build 1358) Cc: FreeBSD Current Subject: Re: azureus -> eclipse -> cairo problems persist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 06:06:40 -0000 Come on, don't create another topic in the wrong place. No excuse. On Sat, 05 Nov 2005 23:07:36 -0600, Randy Bush wrote: > fresh cvsup, now post 6 release > new world and kernel > upgraded gnome to 2.12 (which removed azureus) > > portupgrade -N net/azureus > > it makes cairo, but eclipse can't find the bit of cairo it wants I have committed a fix for it, give it a try. Cheers, Mezz > Making install in src > test -z "/usr/local/lib" || > /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d "/usr/local/lib" > /bin/sh /usr/ports/graphics/cairo/work/gnome-libtool --mode=install > /usr/bin/install -c -o root -g wheel 'libcairo.la' > '/usr/local/lib/libcairo.la' > /usr/bin/install -c -o root -g wheel .libs/libcairo.so.2 > /usr/local/lib/libcairo.so.2 > (cd /usr/local/lib && { ln -s -f libcairo.so.2 libcairo.so || { rm -f > libcairo.so && ln -s libcairo.so.2 libcairo.so; }; }) > (cd /usr/local/lib && { ln -s -f libcairo.so.2 libcairo.so || { rm -f > libcairo.so && ln -s libcairo.so.2 libcairo.so; }; }) > /usr/bin/install -c -o root -g wheel .libs/libcairo.a > /usr/local/lib/libcairo.a > ranlib /usr/local/lib/libcairo.a > chmod 644 /usr/local/lib/libcairo.a > ---------------------------------------------------------------------- > Libraries have been installed in: > /usr/local/lib > > If you ever happen to want to link against installed libraries > in a given directory, LIBDIR, you must either use libtool, and > specify the full pathname of the library, or use the `-LLIBDIR' > flag during linking and do at least one of the following: > - add LIBDIR to the `LD_LIBRARY_PATH' environment variable > during execution > - add LIBDIR to the `LD_RUN_PATH' environment variable > during linking > - use the `-Wl,--rpath -Wl,LIBDIR' linker flag > > See any operating system documentation about shared libraries for > more information, such as the ld(1) and ld.so(8) manual pages. > ---------------------------------------------------------------------- > test -z "/usr/local/include/cairo" || > /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d > "/usr/local/include/cairo" > install -o root -g wheel -m 444 'cairo.h' > '/usr/local/include/cairo/cairo.h' > install -o root -g wheel -m 444 'cairo-features.h' > '/usr/local/include/cairo/cairo-features.h' > install -o root -g wheel -m 444 'cairo-ft.h' > '/usr/local/include/cairo/cairo-ft.h' > install -o root -g wheel -m 444 'cairo-pdf.h' > '/usr/local/include/cairo/cairo-pdf.h' > install -o root -g wheel -m 444 'cairo-ps.h' > '/usr/local/include/cairo/cairo-ps.h' > install -o root -g wheel -m 444 'cairo-xlib.h' > '/usr/local/include/cairo/cairo-xlib.h' > install -o root -g wheel -m 444 'cairo-xlib-xrender.h' > '/usr/local/include/cairo/cairo-xlib-xrender.h' > Making install in doc > Making install in public > installfiles=`echo ./html/*`; if test "$installfiles" = './html/*'; > then echo '-- Nothing to install' ; else > /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d > /usr/local/share/doc/cairo/cairo; for i in $installfiles; do echo '-- > Installing '$i ; install -o root -g wheel -m 444 $i > /usr/local/share/doc/cairo/cairo; done; echo '-- Installing > ./html/index.sgml' ; install -o root -g wheel -m 444 ./html/index.sgml > /usr/local/share/doc/cairo/cairo || :; fi > -- Installing ./html/Drawing.html > -- Installing ./html/Fonts.html > -- Installing ./html/Support.html > -- Installing ./html/Surfaces.html > -- Installing ./html/bindings-errors.html > -- Installing ./html/bindings-fonts.html > -- Installing ./html/bindings-memory.html > -- Installing ./html/bindings-overloading.html > -- Installing ./html/bindings-path.html > -- Installing ./html/bindings-patterns.html > -- Installing ./html/bindings-return-values.html > -- Installing ./html/bindings-streams.html > -- Installing ./html/bindings-surfaces.html > -- Installing ./html/cairo-Error-handling.html > -- Installing ./html/cairo-Font-Options.html > -- Installing ./html/cairo-FreeType-Fonts.html > -- Installing ./html/cairo-Glitz-Surfaces.html > -- Installing ./html/cairo-Image-Surfaces.html > -- Installing ./html/cairo-PDF-Surfaces.html > -- Installing ./html/cairo-PNG-Support.html > -- Installing ./html/cairo-Paths.html > -- Installing ./html/cairo-Patterns.html > -- Installing ./html/cairo-PostScript-Surfaces.html > -- Installing ./html/cairo-Scaled-Fonts.html > -- Installing ./html/cairo-Text.html > -- Installing ./html/cairo-Transformations.html > -- Installing ./html/cairo-Types.html > -- Installing ./html/cairo-Version-Information.html > -- Installing ./html/cairo-Win32-Fonts.html > -- Installing ./html/cairo-Win32-Surfaces.html > -- Installing ./html/cairo-XLib-Surfaces.html > -- Installing ./html/cairo-cairo-font-face-t.html > -- Installing ./html/cairo-cairo-matrix-t.html > -- Installing ./html/cairo-cairo-surface-t.html > -- Installing ./html/cairo-cairo-t.html > -- Installing ./html/cairo.devhelp > -- Installing ./html/home.png > -- Installing ./html/index.html > -- Installing ./html/index.sgml > -- Installing ./html/ix01.html > -- Installing ./html/language-bindings.html > -- Installing ./html/left.png > -- Installing ./html/pt01.html > -- Installing ./html/pt02.html > -- Installing ./html/right.png > -- Installing ./html/style.css > -- Installing ./html/up.png > -- Installing ./html/index.sgml > Making install in test > test -z "/usr/local/libdata/pkgconfig" || > /usr/ports/graphics/cairo/work/cairo-1.0.2/install-sh -d > "/usr/local/libdata/pkgconfig" > install -o root -g wheel -m 444 'cairo.pc' > '/usr/local/libdata/pkgconfig/cairo.pc' > ===> Running ldconfig > /sbin/ldconfig -m /usr/local/lib > ===> Registering installation for cairo-1.0.2 > ===> Returning to build of eclipse-3.1.1_1 > Error: shared library "cairo.1" does not exist > *** Error code 1 > > Stop in /usr/ports/java/eclipse. > *** Error code 1 > > Stop in /usr/ports/net/azureus. > ** Command failed [exit code 1]: /usr/bin/script -qa > /tmp/portupgrade92733.0 make JAVA_EXTRACT=yes > ** Fix the problem and try again. > ** Listing the failed packages (*:skipped / !:failed) > ! net/azureus (dependent libraries) > ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 06:16:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81AA16A41F for ; Sun, 6 Nov 2005 06:16:27 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9095343D45 for ; Sun, 6 Nov 2005 06:16:27 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EYdpK-0003Wy-RA; Sun, 06 Nov 2005 06:16:27 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EYdpH-0009mk-Rm; Sat, 05 Nov 2005 20:16:23 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17261.40887.245722.400198@roam.psg.com> Date: Sat, 5 Nov 2005 20:16:23 -1000 To: "Jeremy Messenger" References: <17261.36760.762443.538898@roam.psg.com> Cc: FreeBSD Current Subject: Re: azureus -> eclipse -> cairo problems persist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 06:16:27 -0000 > Come on, don't create another topic in the wrong place. No excuse. [ for those who care about such trivia ] when i wake up, i purge all of yesterday's deleted mail. so i had no old one on which to hang it. sorry. Others have excuses, I have my reasons why... -- Nickel Creek in "Reasons Why" > I have committed a fix for it, give it a try. cvsupping now and will build while i myself am supping. thanks! randy From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 09:09:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79C4116A41F; Sun, 6 Nov 2005 09:09:20 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD3143D46; Sun, 6 Nov 2005 09:09:19 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id DBC43636F; Sun, 6 Nov 2005 18:10:35 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16125-01; Sun, 6 Nov 2005 18:09:13 +0900 (JST) Received: from flora220.uki-uki.net (231.76.229.210.airh.alpha-net.ne.jp [210.229.76.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 70F0E61C7; Sun, 6 Nov 2005 18:09:07 +0900 (JST) Date: Sun, 06 Nov 2005 18:06:01 +0900 Message-ID: From: SUZUKI Shinsuke To: sean@mcneil.com X-cite: xcite 1.33 In-Reply-To: <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 09:09:20 -0000 Hello Sean, >>>>> On Sat, 5 Nov 2005 14:39:13 -0800 >>>>> sean@mcneil.com(Sean McNeil) said: > > sean> ping6 does NOT work for > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > sean> 2002:18c7:2d36:: > > > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > > see an error message from your kernel like following? > > dc0: possible hardware address duplication detected, disable IPv6 > No, nothing like that in any logs. I can't see how there could > suddenly be a duplication of hardware addresses. I agree, though, > that IPv6 is disabled for dc0. Some change in the kernel has caused > this. I tried the same configuration (with the different interface card) using the latest RELENG-6 in my environment, but I couldn't reproduce your problem. So could you please show me the result of the following commands? - netstat -rnf inet6 - ndp -i dc0 - ndp -na - kernel log message after sysctl -w net.inet6.icmp6.nd6_debug=1 (if exists) > Two things to note: > The dc0 interface has option VLAN_MTU. Don't know why. > The dc0 interface is my gateway with ipv4mapping. At least these two does not seem to be relating to this problem. Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 09:20:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B3216A41F for ; Sun, 6 Nov 2005 09:20:13 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 405DB43D49 for ; Sun, 6 Nov 2005 09:20:11 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000027920.msg for ; Sun, 06 Nov 2005 15:20:03 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 88046, updated: 3.11.2005] To: kuba@lbl.pl References: <20051027022313.R675@kushnir1.kiev.ua> <43602F2F.7080500@samsco.org> <200510281404.33462.jhb@freebsd.org> <200510311955.13137.max@love2party.net> <20051105213753.GB26532@lbl.pl> From: Victor Snezhko Date: Sun, 06 Nov 2005 15:19:52 +0600 In-Reply-To: <20051105213753.GB26532@lbl.pl> (kuba@lbl.pl's message of "Sat, 5 Nov 2005 22:37:53 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Sun, 06 Nov 2005 15:20:03 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Cc: freebsd-current@freebsd.org Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 09:20:13 -0000 KubaTyszko writes: > hi. > did we have that fixed or the bug already occurs ? Not yet. I'm still trying to figure out what code corrupts the callwheel in kern_timeout.c. I'm not a kernel guru so the progress is slow. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 10:39:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09CCA16A41F for ; Sun, 6 Nov 2005 10:39:05 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from efacilitas.de (smtp.efacilitas.de [85.10.196.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9536A43D45 for ; Sun, 6 Nov 2005 10:39:04 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-37-245.dynamic.qsc.de [212.202.37.245]) by efacilitas.de (Postfix) with ESMTP id 3212B4B01F; Sun, 6 Nov 2005 11:46:38 +0100 (CET) Received: from [192.168.1.4] (syn.local [192.168.1.4]) by eurystheus.local (Postfix) with ESMTP id 36901332E4D; Sun, 6 Nov 2005 11:37:58 +0100 (CET) Message-ID: <436DDCFE.6050808@cs.tu-berlin.de> Date: Sun, 06 Nov 2005 11:37:50 +0100 From: Bjoern Koenig User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <435F2BCE.1040704@cs.tu-berlin.de> <20051026073915.GA77249@xor.obsecurity.org> <4360B263.1070802@cs.tu-berlin.de> <20051027173550.GA81309@xor.obsecurity.org> In-Reply-To: <20051027173550.GA81309@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: deadlocks with SMP and Pentium 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 10:39:05 -0000 Kris Kennaway wrote: > On Thu, Oct 27, 2005 at 12:56:35PM +0200, Bjoern Koenig wrote: > >>Kris Kennaway wrote: >> >> >>>You need to break to DDB, trace processes and examine lock state with >>>commands like 'show alllocks' and 'show lockedvnods' to see what is >>>going on. >> >>Unfortunately the machine freezes completely and I can't break to the >>debugger anymore. > > > Try with KDB_STOP_NMI (called STOP_NMI) in 7.0. This didn't help either, but finally I found a solution. The server worked fine for a while; the only difference was that I used a PCI ATA controller at that time. So I thought that it must have something to do with the system BIOS or the onboard ATA controller. In a discussion forum someone gave the hint to change the hard disk drive settings in the BIOS setup from "Auto" to a user defined value. I can't really understand why FreeBSD with SMPng stumble on this, but surprisingly it seems like that it works now. It must be a weird BIOS or hardware bug. Many thanks for your assistance. Björn From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 12:06:03 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2641616A41F; Sun, 6 Nov 2005 12:06:03 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (mail-svr1.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F4043D67; Sun, 6 Nov 2005 12:06:02 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 8AAA3346E0; Sun, 6 Nov 2005 05:06:01 -0700 (MST) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07643-02; Sun, 6 Nov 2005 05:06:01 -0700 (MST) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 2B1F5346D3; Sun, 6 Nov 2005 05:06:01 -0700 (MST) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id CADDD3F71; Sun, 6 Nov 2005 05:06:00 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id B40F43F6C; Sun, 6 Nov 2005 05:06:00 -0700 (MST) Date: Sun, 6 Nov 2005 05:06:00 -0700 (MST) From: Vaibhave Agarwal To: current@freebsd.org, freebsd-net@freebsd.org, jhb@freebsd.org In-Reply-To: Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> <20051028105057.J20147@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: chmr@edvz.tu-graz.ac.at, chris@gnome.co.uk Subject: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 12:06:03 -0000 hi, FreeBSD 6.0 always uses local APIC for the clock. But on my Pentium 3, 850 MHz machine, it doesnt detect local APIC and falls back to using the motherboard clock for the clock interrupts. I figured this out by printing the value of "using_lapic_timer" variable in the sys/i386/isa/clock.c file, which is always 0. But when I use Intel's 3GHz - 64 bit Xeon processor, it detects local APIC and all works fine. Can someone please tell me the reason, why local APIC doesnt work for the Pentium 3 machines ? Or is there a way to fix this ? Thanks vaibhave From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 12:44:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E94216A41F; Sun, 6 Nov 2005 12:44:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8B0F43D46; Sun, 6 Nov 2005 12:44:46 +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.4/8.13.4) with ESMTP id jA6CijoW005723; Sun, 6 Nov 2005 07:44:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA6Cij4U086024; Sun, 6 Nov 2005 07:44:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C12B97302F; Sun, 6 Nov 2005 07:44:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051106124444.C12B97302F@freebsd-current.sentex.ca> Date: Sun, 6 Nov 2005 07:44:44 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 12:44:47 -0000 TB --- 2005-11-06 11:13:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-06 11:13:45 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-11-06 11:13:45 - cleaning the object tree TB --- 2005-11-06 11:14:13 - checking out the source tree TB --- 2005-11-06 11:14:13 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-11-06 11:14:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-06 11:21:16 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-06 11:21:16 - cd /src TB --- 2005-11-06 11:21:16 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-11-06 12:25:39 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 12:25:39 - cd /src TB --- 2005-11-06 12:25:39 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 6 12:25:39 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 6 12:39:00 UTC 2005 TB --- 2005-11-06 12:39:00 - generating LINT kernel config TB --- 2005-11-06 12:39:00 - cd /src/sys/alpha/conf TB --- 2005-11-06 12:39:00 - /usr/bin/make -B LINT TB --- 2005-11-06 12:39:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 12:39:00 - cd /src TB --- 2005-11-06 12:39:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 6 12:39:01 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:85: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:2:1: this is the location of the previous definition *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-06 12:44:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-06 12:44:44 - ERROR: failed to build lint kernel TB --- 2005-11-06 12:44:44 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 13:30:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 739F216A41F for ; Sun, 6 Nov 2005 13:30:50 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E9B843D46 for ; Sun, 6 Nov 2005 13:30:49 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so206338wxc for ; Sun, 06 Nov 2005 05:30:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RkEMzE0qlZoNpS9T3qro/4ujJBW+8W/7144jrlwWt38T7kc9vU5jo8mE9faJbY3WuPH3iOfkeQZTviCi8PG0KCytlr6kuADTGeuinCZlF7T91ULySasNtqoWwRKGqGn6ZUOVENGGpfO4XeLijJrUnZKPlMhjsK/RPykGOVH2ioQ= Received: by 10.70.109.20 with SMTP id h20mr3906940wxc; Sun, 06 Nov 2005 05:30:49 -0800 (PST) Received: by 10.70.105.13 with HTTP; Sun, 6 Nov 2005 05:30:49 -0800 (PST) Message-ID: <84dead720511060530w9d6fed6x4bef43b66567ffb3@mail.gmail.com> Date: Sun, 6 Nov 2005 19:00:49 +0530 From: Joseph Koshy To: Vaibhave Agarwal In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051027233636.GA39380@dmw.hopto.org> <20051028105057.J20147@fledge.watson.org> Cc: chmr@edvz.tu-graz.ac.at, chris@gnome.co.uk, current@freebsd.org Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 13:30:50 -0000 [Freebsd-net trimmed from the CC list]. > But on my Pentium 3, 850 MHz machine, it doesnt detect local > APIC and falls back to using the motherboard clock for the > clock interrupts. Is your machine a UP one? Some P6...P-III UP motherboards keep the local APIC disabled in software. Linux has a boot time option to forcibly enable the CPU's local APIC; we don't have an equivalent. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 14:22:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF0AC16A41F for ; Sun, 6 Nov 2005 14:22:05 +0000 (GMT) (envelope-from geek00l@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA64E43D4C for ; Sun, 6 Nov 2005 14:22:04 +0000 (GMT) (envelope-from geek00l@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so223668wxc for ; Sun, 06 Nov 2005 06:22:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Rbk5Ddb5oClHcnof2P8D3/fDWGmlk35ghR7QVTVL8N6Lsb6MaIrhjhg5L2qyD4gLtmMhJYN0XdGla017XCATeGaVi/33rtWYv82MbpINho/SoPSVlqeFSh2ODeux+0KTOQu0yAYWopnqcxH8mCblVCY0dELRwItFX9XGtUXfXNU= Received: by 10.70.9.5 with SMTP id 5mr3930612wxi; Sun, 06 Nov 2005 06:22:04 -0800 (PST) Received: by 10.70.130.13 with HTTP; Sun, 6 Nov 2005 06:22:04 -0800 (PST) Message-ID: <1bb5dd90511060622x1393b482l70396fabc372348@mail.gmail.com> Date: Sun, 6 Nov 2005 22:22:04 +0800 From: lee sheng To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 6 Released BTX loader issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 14:22:05 -0000 I'm trying to have clean install FreeBSD 6.0 released in my X41 thinkpad by using the cd, however I have problem while booting it in thinkpad X41 when = I load it using usb combo drive. The BTX loader keeps looping and halted someway and I have actually seen this report from previous post but it is not yet been fixed even till the FreeBSD 6.0 release. I would like to know the status and what's actual problem or is there any workaround. Thanks C.S.Lee From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 14:45:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6414E16A425; Sun, 6 Nov 2005 14:45:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF2043D79; Sun, 6 Nov 2005 14:45:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jA6Eix4l007686; Sun, 6 Nov 2005 09:44:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA6Eixvr072676; Sun, 6 Nov 2005 09:44:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 78AC87302F; Sun, 6 Nov 2005 09:44:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051106144459.78AC87302F@freebsd-current.sentex.ca> Date: Sun, 6 Nov 2005 09:44:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 14:45:29 -0000 TB --- 2005-11-06 12:44:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-06 12:44:45 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-11-06 12:44:45 - cleaning the object tree TB --- 2005-11-06 12:45:21 - checking out the source tree TB --- 2005-11-06 12:45:21 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-11-06 12:45:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-06 12:52:16 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-06 12:52:16 - cd /src TB --- 2005-11-06 12:52:16 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-11-06 14:22:43 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 14:22:43 - cd /src TB --- 2005-11-06 14:22:43 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 6 14:22:43 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 6 14:38:35 UTC 2005 TB --- 2005-11-06 14:38:35 - generating LINT kernel config TB --- 2005-11-06 14:38:35 - cd /src/sys/amd64/conf TB --- 2005-11-06 14:38:35 - /usr/bin/make -B LINT TB --- 2005-11-06 14:38:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 14:38:35 - cd /src TB --- 2005-11-06 14:38:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 6 14:38:35 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:85: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:2:1: this is the location of the previous definition *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-06 14:44:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-06 14:44:59 - ERROR: failed to build lint kernel TB --- 2005-11-06 14:44:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 14:49:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB5816A41F for ; Sun, 6 Nov 2005 14:49:24 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CA0343D6D for ; Sun, 6 Nov 2005 14:49:20 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jA6EnILX090753; Sun, 6 Nov 2005 17:49:18 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jA6EnI3t090752; Sun, 6 Nov 2005 17:49:18 +0300 (MSK) (envelope-from yar) Date: Sun, 6 Nov 2005 17:49:17 +0300 From: Yar Tikhiy To: Taras Savchuk Message-ID: <20051106144917.GA81664@comp.chem.msu.su> References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 14:49:24 -0000 On Thu, Nov 03, 2005 at 03:25:28PM +0300, Taras Savchuk wrote: > On 11/3/05, Taras Savchuk wrote: > > > > My SATA HDD with UFS2 crashed. While checking HDD fsck said, that > > alternate super block at block 32 is not present. In 'man fsck' I saw, that > > in UFS2 (my file system) alternate super block is usually located in block > > 160 (For UFS1 - in 32). So the question is: why fsck trying to find > > alternate superblock in wrong block for UFS2? I can suppose, that fsck dont > > know file system type (UFS1 or UFS2) while checking, but such assumption > > seems to be wrong. > > PS: With '-b 160' option fsck done work well. Isn't the type, UFS1 or UFS2, indicated by a magic number in the superblock itself? I used to believe so. If it's true, fsck cannot know the FS type prior to locating a superblock copy. OTOH, with UFS2 having become popular, fsck might try both locations, 32 and 160. Care to file a PR? -- Yar From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 15:05:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AD2416A422 for ; Sun, 6 Nov 2005 15:05:30 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B081243D45 for ; Sun, 6 Nov 2005 15:05:29 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by xproxy.gmail.com with SMTP id i30so221095wxd for ; Sun, 06 Nov 2005 07:05:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pISKGng0NeYY39H/Dk2Ij4Ktnfsh8fNy+3p1W6kMEPX7rsBrobe1NU16vSq9qcK1+jnXfrIJjCF8aVfO38w75GHjGTG1BVKiPItm2WxItAExYmQX6MM+VHZTdIW6nW0IRZEAzCtH0Uyu5d8HHJishriDNV1/yExHEDxrd5MRHpw= Received: by 10.64.185.7 with SMTP id i7mr4325532qbf; Sun, 06 Nov 2005 07:05:28 -0800 (PST) Received: by 10.65.191.18 with HTTP; Sun, 6 Nov 2005 07:05:28 -0800 (PST) Message-ID: Date: Sun, 6 Nov 2005 23:05:28 +0800 From: Xin LI To: Yar Tikhiy In-Reply-To: <20051106144917.GA81664@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> <20051106144917.GA81664@comp.chem.msu.su> Cc: freebsd-current@freebsd.org, Taras Savchuk Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 15:05:30 -0000 SGksIFlhciwKCk9uIDExLzYvMDUsIFlhciBUaWtoaXkgPHlhckBjb21wLmNoZW0ubXN1LnN1PiB3 cm90ZToKW3NuaXBdCj4gSXNuJ3QgdGhlIHR5cGUsIFVGUzEgb3IgVUZTMiwgaW5kaWNhdGVkIGJ5 IGEgbWFnaWMgbnVtYmVyIGluIHRoZQo+IHN1cGVyYmxvY2sgaXRzZWxmPyAgSSB1c2VkIHRvIGJl bGlldmUgc28uICBJZiBpdCdzIHRydWUsIGZzY2sgY2Fubm90Cj4ga25vdyB0aGUgRlMgdHlwZSBw cmlvciB0byBsb2NhdGluZyBhIHN1cGVyYmxvY2sgY29weS4gIE9UT0gsIHdpdGgKPiBVRlMyIGhh dmluZyBiZWNvbWUgcG9wdWxhciwgZnNjayBtaWdodCB0cnkgYm90aCBsb2NhdGlvbnMsIDMyIGFu ZCAxNjAuCj4gQ2FyZSB0byBmaWxlIGEgUFI/CgpUaGF0J3MgY29ycmVjdC4gIEZvcnR1bmF0ZWx5 LCBnaXZlbiB0aGF0IHdlIGhhdmUgc29tZSB3YXlzIHRvIHZhbGlkYXRlCndoZXRoZXIgdGhlIHN1 cGVyYmxvY2sgaXMgdmFsaWQsIGl0IGlzIG5vdCB0b28gaGFyZCB0byBhdXRvbWF0aWNhbGx5CmRl dGVjdCB3aGljaCB0eXBlIHRoZSBGUyBhY3R1YWxseSBpcy4KCkNoZWVycywK From owner-freebsd-current@FreeBSD.ORG Sat Nov 5 22:39:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B7D16A41F; Sat, 5 Nov 2005 22:39:23 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9FA43D45; Sat, 5 Nov 2005 22:39:23 +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 022EDF24A6; Sat, 5 Nov 2005 14:39:23 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00799-04; Sat, 5 Nov 2005 14:39:14 -0800 (PST) Received: from [10.1.0.10] (mobile.mcneil.com [10.1.0.10]) by mail.mcneil.com (Postfix) with ESMTP id A162EF2442; Sat, 5 Nov 2005 14:39:14 -0800 (PST) In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> Content-Transfer-Encoding: 7bit From: Sean McNeil Date: Sat, 5 Nov 2005 14:39:13 -0800 To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Sun, 06 Nov 2005 15:19:37 +0000 Cc: current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Nov 2005 22:39:23 -0000 On Nov 5, 2005, at 11:58 AM, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Fri, 04 Nov 2005 19:36:08 -0800 >>>>>> Sean McNeil said: > > sean> My IMAP server used to work perfectly fine with IPv6 > connections from > sean> evolution. Today, there was some MFCd code that has killed > it. I can > sean> no longer log into my imap server with IPv6. Investigating, > I find that > sean> the interface I have tied to stf0 will not respond. > > When was your working kernel built? I had a working kernel that was built perhaps 3-4 days ago. It is the changes MFCd in the last couple of days that broke things. > sean> ping6 does NOT work for > sean> fe80::203:6dff:fe1a:b19b%dc0 > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > sean> 2002:18c7:2d36:: > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > see an error message from your kernel like following? > > dc0: possible hardware address duplication detected, disable IPv6 No, nothing like that in any logs. I can't see how there could suddenly be a duplication of hardware addresses. I agree, though, that IPv6 is disabled for dc0. Some change in the kernel has caused this. Two things to note: The dc0 interface has option VLAN_MTU. Don't know why. The dc0 interface is my gateway with ipv4mapping. Here are the relevant rc.conf settings... /etc/rc.conf:ipv6_defaultrouter="2002:c058:6301::" /etc/rc.conf:ipv6_enable="YES" /etc/rc.conf:ipv6_gateway_enable="YES" /etc/rc.conf:ipv6_prefix_dc0="2002:18c7:2d36:0000" /etc/rc.conf:ipv6_prefix_sk0="2002:18c7:2d36:0001" /etc/rc.conf:ipv6_router_enable="YES" /etc/rc.conf:stf_interface_ipv4addr="24.199.45.54" /etc/rc.conf.d/ip6addrctl:ipv6_enable="YES" /etc/rc.conf.d/ip6fw:ipv6_firewall_enable="YES" /etc/rc.conf.d/ip6fw:ipv6_firewall_type="/etc/fw/rc.firewall6.rules" /etc/rc.conf.d/ip6fw:ipv6_firewall_quiet="YES" /etc/rc.conf.d/network_ipv6:ipv6_ipv4mapping="YES" /etc/rc.conf.d/route6d:ipv6_router_enable="YES" looking at ip6fw show indicated nothing is being denied. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 15:40:33 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF12916A41F; Sun, 6 Nov 2005 15:40:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFCBE43D46; Sun, 6 Nov 2005 15:40:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1468687 for multiple; Sun, 06 Nov 2005 10:42:30 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA6FeDlR003644; Sun, 6 Nov 2005 10:40:20 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Vaibhave Agarwal Date: Sun, 6 Nov 2005 10:12:55 -0500 User-Agent: KMail/1.8 References: <20051027233636.GA39380@dmw.hopto.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200511061012.57212.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: freebsd-net@FreeBSD.org, current@FreeBSD.org, chris@gnome.co.uk, chmr@edvz.tu-graz.ac.at Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 15:40:33 -0000 On Sunday 06 November 2005 07:06 am, Vaibhave Agarwal wrote: > hi, > > FreeBSD 6.0 always uses local APIC for the clock. > > But on my Pentium 3, 850 MHz machine, it doesnt detect local APIC and > falls back to using the motherboard clock for the clock interrupts. > > I figured this out by printing the value of > "using_lapic_timer" variable in the sys/i386/isa/clock.c file, > which is always 0. > > But when I use Intel's 3GHz - 64 bit Xeon processor, it detects local APIC > and all works fine. > > Can someone please tell me the reason, why local APIC doesnt work for the > Pentium 3 machines ? Or is there a way to fix this ? We don't detect the local APIC via MSR's or the APIC bit in cpu_features, b= ut=20 rely on a working MP Table or MADT table to setup both the local APIC(s) an= d=20 I/O APIC(s). Does your machine have a valid MP Table or an APIC table in i= ts=20 acpidump? Many UP machine BIOSes don't include those tables. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 16:21:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF1516A41F; Sun, 6 Nov 2005 16:21:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E956343D45; Sun, 6 Nov 2005 16:21:23 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jA6GLLBt013387; Sun, 6 Nov 2005 11:21:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA6GLL2i001625; Sun, 6 Nov 2005 11:21:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 755AB7302F; Sun, 6 Nov 2005 11:21:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051106162121.755AB7302F@freebsd-current.sentex.ca> Date: Sun, 6 Nov 2005 11:21:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 16:21:24 -0000 TB --- 2005-11-06 14:44:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-06 14:44:59 - starting HEAD tinderbox run for i386/i386 TB --- 2005-11-06 14:44:59 - cleaning the object tree TB --- 2005-11-06 14:45:36 - checking out the source tree TB --- 2005-11-06 14:45:36 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-11-06 14:45:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-06 14:52:04 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-06 14:52:04 - cd /src TB --- 2005-11-06 14:52:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-11-06 15:56:31 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 15:56:31 - cd /src TB --- 2005-11-06 15:56:31 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 6 15:56:32 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 6 16:14:20 UTC 2005 TB --- 2005-11-06 16:14:20 - generating LINT kernel config TB --- 2005-11-06 16:14:20 - cd /src/sys/i386/conf TB --- 2005-11-06 16:14:20 - /usr/bin/make -B LINT TB --- 2005-11-06 16:14:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 16:14:20 - cd /src TB --- 2005-11-06 16:14:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 6 16:14:20 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/pst/pst-iop.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/pst/pst-pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/pst/pst-raid.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:85: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:2:1: this is the location of the previous definition *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-06 16:21:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-06 16:21:21 - ERROR: failed to build lint kernel TB --- 2005-11-06 16:21:21 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 17:53:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0CB916A41F; Sun, 6 Nov 2005 17:53:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E5F43D46; Sun, 6 Nov 2005 17:53:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jA6HrA63018729; Sun, 6 Nov 2005 12:53:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id jA6HrBpZ049982; Sun, 6 Nov 2005 12:53:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0602E7302F; Sun, 6 Nov 2005 12:53:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051106175310.0602E7302F@freebsd-current.sentex.ca> Date: Sun, 6 Nov 2005 12:53:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 17:53:13 -0000 TB --- 2005-11-06 16:21:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-06 16:21:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-11-06 16:21:21 - cleaning the object tree TB --- 2005-11-06 16:21:55 - checking out the source tree TB --- 2005-11-06 16:21:55 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-11-06 16:21:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-06 16:28:23 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-06 16:28:23 - cd /src TB --- 2005-11-06 16:28: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 TB --- 2005-11-06 17:32:28 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 17:32:28 - cd /src TB --- 2005-11-06 17:32:28 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 6 17:32:28 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 6 17:47:29 UTC 2005 TB --- 2005-11-06 17:47:29 - generating LINT kernel config TB --- 2005-11-06 17:47:29 - cd /src/sys/pc98/conf TB --- 2005-11-06 17:47:29 - /usr/bin/make -B LINT TB --- 2005-11-06 17:47:29 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 17:47:29 - cd /src TB --- 2005-11-06 17:47:29 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 6 17:47:29 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:87: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:3:1: this is the location of the previous definition *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-06 17:53:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-06 17:53:10 - ERROR: failed to build lint kernel TB --- 2005-11-06 17:53:10 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 19:24:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE8516A41F; Sun, 6 Nov 2005 19:24:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07CAC43D66; Sun, 6 Nov 2005 19:24:23 +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.4/8.13.4) with ESMTP id jA6JOMTR030085; Sun, 6 Nov 2005 14:24:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA6JOMLP039901; Sun, 6 Nov 2005 14:24:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 680537302F; Sun, 6 Nov 2005 14:24:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051106192407.680537302F@freebsd-current.sentex.ca> Date: Sun, 6 Nov 2005 14:24:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 19:24:28 -0000 TB --- 2005-11-06 17:53:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-06 17:53:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-11-06 17:53:11 - cleaning the object tree TB --- 2005-11-06 17:53:42 - checking out the source tree TB --- 2005-11-06 17:53:42 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-11-06 17:53:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-06 18:00:43 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-06 18:00:43 - cd /src TB --- 2005-11-06 18:00:43 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-11-06 19:05:51 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 19:05:51 - cd /src TB --- 2005-11-06 19:05:51 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 6 19:05:51 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Nov 6 19:18:43 UTC 2005 TB --- 2005-11-06 19:18:43 - generating LINT kernel config TB --- 2005-11-06 19:18:43 - cd /src/sys/sparc64/conf TB --- 2005-11-06 19:18:43 - /usr/bin/make -B LINT TB --- 2005-11-06 19:18:43 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-06 19:18:43 - cd /src TB --- 2005-11-06 19:18:43 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 6 19:18:43 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:87: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:3:1: this is the location of the previous definition *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-06 19:24:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-06 19:24:07 - ERROR: failed to build lint kernel TB --- 2005-11-06 19:24:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 20:26:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 128AE16A41F for ; Sun, 6 Nov 2005 20:26:45 +0000 (GMT) (envelope-from creep@desk.pl) Received: from hera.desk.pl (hera.desk.pl [81.219.9.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9929843D45 for ; Sun, 6 Nov 2005 20:26:44 +0000 (GMT) (envelope-from creep@desk.pl) Received: from localhost (hera.local [127.0.0.1]) by hera.desk.pl (Postfix) with ESMTP id 8A0F875C1C2 for ; Sun, 6 Nov 2005 21:27:20 +0100 (CET) Received: from hera.desk.pl ([127.0.0.1]) by localhost (hera [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30205-02 for ; Sun, 6 Nov 2005 21:27:16 +0100 (CET) Received: from [192.168.0.64] (sifr.dembego6.waw.pl [62.233.200.81]) by hera.desk.pl (Postfix) with ESMTP id 4091875C193 for ; Sun, 6 Nov 2005 21:27:16 +0100 (CET) Message-ID: <436E66FB.60700@desk.pl> Date: Sun, 06 Nov 2005 21:26:35 +0100 From: Marcin Koziej User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051018) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Skaner Antywirusowy DESK.pl Subject: NVidia driver for amd64 / Page Attribute Table status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 20:26:45 -0000 Hi, I have searched for some information about nVidia FreeBSD-amd64 driver and reasons why it is not availible, but the whole situation seems to be very mysterious. There are comments on nVidia forums from september by mr. Zander from nVidia: "There are technical problems with the FreeBSD/amd64 kernel that gate NVIDIA graphics driver support for this platform. NVIDIA has brought these problems up with FreeBSD developers and has been working with one of them to make reliable support for FreeBSD/amd64 technically possible, but unfortunately we can't provide a schedule for when this will be complete." (http://www.nvnews.net/vbulletin/showthread.php?t=41545&page=2) Both the developer and the 'technical problems with FreeBSD' are kept secret... There are some clues in freebsd-current archive: "There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience." and "Actually I think that the feature we are talking about (PAT) is relevant to both amd64 and i386. Proper support for PAT is required for decent PCI Express performance, as I understand it." (http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052740.html http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052746.html) Is Page Attribute Table feature blocking nVidia drivers? What is the status of this feature then? Can someone informed enough shed some light on the story? Thanks for Your time, m. From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 21:11:40 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C61A716A41F for ; Sun, 6 Nov 2005 21:11:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1418143D46 for ; Sun, 6 Nov 2005 21:11:39 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA6LBPxA047576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Nov 2005 00:11:25 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA6LBPSR047575; Mon, 7 Nov 2005 00:11:25 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2005 00:11:24 +0300 From: Gleb Smirnoff To: Xin LI Message-ID: <20051106211124.GL91530@cell.sick.ru> References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> <20051106144917.GA81664@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: Yar Tikhiy , freebsd-current@FreeBSD.org, Taras Savchuk Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 21:11:40 -0000 On Sun, Nov 06, 2005 at 11:05:28PM +0800, Xin LI wrote: X> On 11/6/05, Yar Tikhiy wrote: X> > Isn't the type, UFS1 or UFS2, indicated by a magic number in the X> > superblock itself? I used to believe so. If it's true, fsck cannot X> > know the FS type prior to locating a superblock copy. OTOH, with X> > UFS2 having become popular, fsck might try both locations, 32 and 160. X> > Care to file a PR? X> X> That's correct. Fortunately, given that we have some ways to validate X> whether the superblock is valid, it is not too hard to automatically X> detect which type the FS actually is. I think this feature is already present in libufs, since dumpfs(8) can detect UFS1/UFS2 type of filesystem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 21:57:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1063016A41F; Sun, 6 Nov 2005 21:57:27 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from magnum.mistaken-identity.co.uk (slayer-of.demon.co.uk [62.49.5.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC3243D48; Sun, 6 Nov 2005 21:57:25 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from mail pickup service by magnum.mistaken-identity.co.uk with Microsoft SMTPSVC; Sun, 6 Nov 2005 21:57:05 +0000 thread-index: AcXjHQUlbrfiVjCqTZqC+fU7BfHYkg== X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Message-ID: <001901c5e31d$05273720$fe07000a@Home.local> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ovGJ6S7vlcCvTAVWqWZdfIcZAUKIyYoXjtRikaRLAcjEnfKfbPXATLOkD2iUlQMRKPznA70MJqiFe1x/JNchskdhyIme68sJuXuGbUv0NYHAZaHHR7f6itoevr42+IK83CI+TwqFF0mIomKAF6Ch3u11KfvlgZAOojqKwXW/JmA= Date: Sun, 6 Nov 2005 21:57:02 -0000 From: "Renato Botelho" X-Mailer: Microsoft CDO for Exchange 2000 To: In-Reply-To: <436B810A.7040908@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <436B810A.7040908@FreeBSD.org> X-BeenThere: freebsd-stable@freebsd.org Content-Class: urn:content-classes:message X-Mailman-Version: 2.1.5 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Precedence: list Sender: Errors-To: owner-freebsd-stable@freebsd.org X-OriginalArrivalTime: 06 Nov 2005 21:57:05.0449 (UTC) FILETIME=[069DD190:01C5E31D] X-Mailman-Approved-At: Sun, 06 Nov 2005 22:07:45 +0000 Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.0 Released X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2005 21:57:27 -0000 On 11/4/05, Scott Long wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > It is my great pleasure and privilege to announce the availability of > FreeBSD 6.0-RELEASE. This release is the next step in delivering the > high performance and enterprise features that have been under > development in the FreeBSD 5.x series for that last several years. > Some of the many changes since 5.4 include: I'm having some troubles with locale after upgrade to RELENG_6. one example, perl warning me about my locale: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL =3D "en_US.ISO8859-1", LANG =3D "en_US.ISO8859-1" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). And on another machine, when I go to gnome, this start with locale US-ASCII and I can't use acents on OpenOffice. Am I doing anything wrong? -- Renato Botelho _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:20:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFD6F16A41F for ; Sun, 6 Nov 2005 22:20:39 +0000 (GMT) (envelope-from freebsd@powered.net) Received: from valimar.ibest.com.br (mx11.ibest.com.br [200.181.68.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B9143D62 for ; Sun, 6 Nov 2005 22:20:38 +0000 (GMT) (envelope-from freebsd@powered.net) Received: from [127.0.0.1] (centaurus.ibest.com.br [200.181.68.107]) by valimar.ibest.com.br (Postfix) with ESMTP id 05E1117C04F; Sun, 6 Nov 2005 20:20:33 -0200 (BRDT) Message-ID: <436E81A0.5070809@powered.net> Date: Sun, 06 Nov 2005 20:20:16 -0200 From: Rainer Alves User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051105) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renato Botelho , freebsd-current@freebsd.org References: <436B810A.7040908@FreeBSD.org> <001901c5e31d$05273720$fe07000a@Home.local> In-Reply-To: <001901c5e31d$05273720$fe07000a@Home.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-iBEST-MailScanner-Information: Please contact the ISP for more information X-MailScanner-From: freebsd@powered.net Cc: Subject: Re: FreeBSD 6.0 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 22:20:39 -0000 Renato Botelho wrote: >I'm having some troubles with locale after upgrade to RELENG_6. > >one example, perl warning me about my locale: > >perl: warning: Setting locale failed. >perl: warning: Please check that your locale settings: > LC_ALL = "en_US.ISO8859-1", > LANG = "en_US.ISO8859-1" > are supported and installed on your system. >perl: warning: Falling back to the standard locale ("C"). > >And on another machine, when I go to gnome, this start with locale >US-ASCII and I can't use acents on OpenOffice. > >Am I doing anything wrong? > >-- >Renato Botelho > > Diz ae Renato, You should consider recompiling lang/perl58, as this locale problem usually is the result of stale libraries or linking with an incorrect library version (chances are your perl binary is linked to libc.so.5 instead of .6). -- Rainer Alves BrasilTelecom From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:25:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D03F116A41F for ; Sun, 6 Nov 2005 22:25:53 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD9C43D4C for ; Sun, 6 Nov 2005 22:25:53 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from weirdo by tehran.lain.pl with local (Exim 4.54 (FreeBSD)) id 1EYsxN-000AQh-V5 for freebsd-current@freebsd.org; Sun, 06 Nov 2005 23:25:45 +0100 Date: Sun, 6 Nov 2005 23:25:45 +0100 From: Stanislaw Halik To: freebsd-current@freebsd.org Message-ID: <20051106222545.GA40048@tehran.lain.pl> References: <436B810A.7040908@FreeBSD.org> <001901c5e31d$05273720$fe07000a@Home.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <001901c5e31d$05273720$fe07000a@Home.local> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Subject: Re: FreeBSD 6.0 Released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 22:25:53 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Renato Botelho wrote: > I'm having some troubles with locale after upgrade to RELENG_6. > one example, perl warning me about my locale: > perl: warning: Setting locale failed. > perl: warning: Please check that your locale settings: > LC_ALL =3D "en_US.ISO8859-1", > LANG =3D "en_US.ISO8859-1" > are supported and installed on your system. > perl: warning: Falling back to the standard locale ("C"). recompiling all ports using locale (and probably everything else, too, since there was a libc.so number bumpage) seems to help. regards, --=20 Stanis=B3aw Halik, http://tehran.lain.pl --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDboLpadU+vjT62TERAkeEAJwJb3G4bBmeyokFIbT9MyNlVrE4+QCfWwoI BgPGvEyLtVkgDbjznOjbRfc= =KTAD -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:40:00 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1C9C16A41F; Sun, 6 Nov 2005 22:40:00 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (mail-svr1.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FB8743D6E; Sun, 6 Nov 2005 22:40:00 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id F0061346E0; Sun, 6 Nov 2005 15:39:58 -0700 (MST) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20413-02; Sun, 6 Nov 2005 15:39:58 -0700 (MST) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 99F2A346D3; Sun, 6 Nov 2005 15:39:58 -0700 (MST) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 779AD3F71; Sun, 6 Nov 2005 15:39:58 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 5F6723F6C; Sun, 6 Nov 2005 15:39:58 -0700 (MST) Date: Sun, 6 Nov 2005 15:39:58 -0700 (MST) From: Vaibhave Agarwal To: John Baldwin In-Reply-To: <200511061012.57212.jhb@FreeBSD.org> Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> <200511061012.57212.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd-net@FreeBSD.org, freebsd-acpi@freebsd.org, current@FreeBSD.org, chris@gnome.co.uk Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 22:40:00 -0000 On Sun, 6 Nov 2005, John Baldwin wrote: > We don't detect the local APIC via MSR's or the APIC bit in cpu_features, but > rely on a working MP Table or MADT table to setup both the local APIC(s) and > I/O APIC(s). Does your machine have a valid MP Table or an APIC table in its > acpidump? Many UP machine BIOSes don't include those tables. > I think you are right. There is no valid APIC table in the acpidump. The only place where APIC is mentioned in the acpidump(8) is in following: Scope (\_SB) { Name (APIC, 0x00) Method (_PIC, 1, NotSerialized) { Store (Arg0, APIC) } } And I suppose APIC is disabled in the BIOS too. Is there a way to enable APIC using software, without changing the BIOS, since I dont have access to the BIOS, as it is a remote machine (with root access) ? Thanks vaibhave From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 22:45:03 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C351E16A41F; Sun, 6 Nov 2005 22:45:03 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C231E43D6A; Sun, 6 Nov 2005 22:44:58 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-0-107.dsl.snfc21.pacbell.net [71.139.0.107]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA6MiUxq018172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Nov 2005 14:44:31 -0800 Message-ID: <436E874E.4010305@root.org> Date: Sun, 06 Nov 2005 14:44:30 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vaibhave Agarwal References: <20051027233636.GA39380@dmw.hopto.org> <200511061012.57212.jhb@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-acpi@FreeBSD.org, chris@gnome.co.uk, current@FreeBSD.org, John Baldwin Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 22:45:04 -0000 Vaibhave Agarwal wrote: > On Sun, 6 Nov 2005, John Baldwin wrote: > > >>We don't detect the local APIC via MSR's or the APIC bit in cpu_features, but >>rely on a working MP Table or MADT table to setup both the local APIC(s) and >>I/O APIC(s). Does your machine have a valid MP Table or an APIC table in its >>acpidump? Many UP machine BIOSes don't include those tables. >> > > > I think you are right. > There is no valid APIC table in the acpidump. > The only place where APIC is mentioned in the acpidump(8) is in following: > > Scope (\_SB) > { > Name (APIC, 0x00) > Method (_PIC, 1, NotSerialized) > { > Store (Arg0, APIC) > } > } > > > And I suppose APIC is disabled in the BIOS too. > Is there a way to enable APIC using software, without changing the BIOS, > since I dont have access to the BIOS, as it is a remote machine (with > root access) ? The above references to APIC just store a value in a convenience variable. If there's nothing else in the AML that references the \_SB.APIC variable, then it has no effect on the system. In that case, the only way to get APIC support on that machine is to implement another way of enumerating it. -- Nate From owner-freebsd-current@FreeBSD.ORG Sun Nov 6 23:19:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4192016A41F for ; Sun, 6 Nov 2005 23:19:30 +0000 (GMT) (envelope-from ob@gruft.de) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A16C643D45 for ; Sun, 6 Nov 2005 23:19:27 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.54 (FreeBSD)) id 1EYtnJ-000Cjl-WA for freebsd-current@freebsd.org; Mon, 07 Nov 2005 00:19:25 +0100 Date: Mon, 7 Nov 2005 00:19:25 +0100 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20051106231925.GC23749@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org References: <84099c3d0511030325q6d1df92ag77310ff1b03a2d15@mail.gmail.com> <84099c3d0511030425q3592a288he254cb5f97f976b6@mail.gmail.com> <20051106144917.GA81664@comp.chem.msu.su> <20051106211124.GL91530@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051106211124.GL91530@cell.sick.ru> User-Agent: Mutt/1.5.11 Sender: Oliver Brandmueller Subject: Re: May be a bug in fsck [ after super block crash on 5.4-STABLE ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Nov 2005 23:19:30 -0000 Hi. On Mon, Nov 07, 2005 at 12:11:24AM +0300, Gleb Smirnoff wrote: > X> That's correct. Fortunately, given that we have some ways to validate > X> whether the superblock is valid, it is not too hard to automatically > X> detect which type the FS actually is. > > I think this feature is already present in libufs, since dumpfs(8) > can detect UFS1/UFS2 type of filesystem. Well, the original problem was in incorrect superblock. To find the second one you need to check 32 or 160 for an valid superblock. If you can get the information if it's UFS1 or UFS2 only from the superblock, then you gotta check both (in the worst case). Kinda chicken and egg problem. - 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 Mon Nov 7 00:44:55 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B151416A41F for ; Mon, 7 Nov 2005 00:44:55 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from bilbo.mebtel.net (bilbo.mebtel.net [64.40.67.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C9843D66 for ; Mon, 7 Nov 2005 00:44:52 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from localhost (localhost [127.0.0.1]) by bilbo.mebtel.net (Postfix) with ESMTP id 92D292A7F0 for ; Sun, 6 Nov 2005 19:44:51 -0500 (EST) Received: from bilbo.mebtel.net ([127.0.0.1]) by localhost (bilbo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06844-08 for ; Sun, 6 Nov 2005 19:44:51 -0500 (EST) Received: from lorne.arm.org (66-79-79-177.dsl.mebtel.net [66.79.79.177]) by bilbo.mebtel.net (Postfix) with ESMTP id 04F712A7ED for ; Sun, 6 Nov 2005 19:44:51 -0500 (EST) Received: from lorne.arm.org (localhost [127.0.0.1]) by lorne.arm.org (8.13.4/8.13.4) with ESMTP id jA70iof3012177 for ; Sun, 6 Nov 2005 19:44:50 -0500 (EST) (envelope-from dlt@lorne.arm.org) Received: (from dlt@localhost) by lorne.arm.org (8.13.4/8.13.4/Submit) id jA70ioNQ012174; Sun, 6 Nov 2005 19:44:50 -0500 (EST) (envelope-from dlt) Date: Sun, 6 Nov 2005 19:44:50 -0500 (EST) Message-Id: <200511070044.jA70ioNQ012174@lorne.arm.org> From: Derek Tattersall To: current@FreeBSD.org X-Virus-Scanned: by amavisd-new at mebtel.net Cc: Subject: Panic with GENERIC from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 00:44:55 -0000 An i386 GENERIC kernel with an ndisgen'd wrapper for bcmwl5_sys driver for a Linksys WPC54G panics as it attempts to DHCP. The back trace reads (hand transcribed): kdb_enter (c08y0b30) at kdb_enter + 0x2b panic(c08773ef,c082441,0,d52bb944,c07daf6) at panic+0x127 mb_free_ext(c3737e00) at mb_free_ext +0x185 m_freem(c3737e00,c34d5cf8,0,c34e2800,c3737e00) at m_freem + 0x1a ndis_rxeof(c34ec200,d511b9e8,1,c34fc7d4,d51bbb7e) at ndis_rxeof + 0xb9 _end(c3785414,0,c34fc7d4,c34fc000,c34fc7d4)at 0xc333dd61 BCMWL5_SYS_drv_data_start(c3652228,17,7a171200,d51bf098,0) at 0xc09ba8bb BCMWL5_SYS_drv_data_start() at BCMWL5_SYS_drv_data_start + 0x3110 A GENERIC kernel from a week ago with an ndisgen'd wrapper for the same driver works fine. Di I cvsup in the middle of a commit? I noticed Bill had committed some changes to the NDIS later later this afternoon, but they appeared to be for an intel driver. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 00:45:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE9FC16A41F for ; Mon, 7 Nov 2005 00:45:34 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S1.cableone.net (s1.cableone.net [24.116.0.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5707243D49 for ; Mon, 7 Nov 2005 00:45:34 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 36423144 for ; Sun, 06 Nov 2005 17:45:56 -0700 Date: Sun, 6 Nov 2005 18:50:48 -0600 From: Vulpes Velox To: freebsd-current@freebsd.org Message-ID: <20051106185048.20db1c5e@vixen42.vulpes> In-Reply-To: <20051103214201.5536951d@vixen42.vulpes> References: <20051103214201.5536951d@vixen42.vulpes> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-NotAscii: charset=us-ascii X-IP-stats: Incoming Last 0, First 171, in=286, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Subject: Re: quake 4 oddity with hardlocking during install on 6.0-rc1 (FIXED) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 00:45:35 -0000 On Thu, 3 Nov 2005 21:42:01 -0600 Vulpes Velox wrote: > Well have run into a odd problem. I got linux-gtk, linux-dri, and > the nvidia driver installed and providing linux libs for it. The > problem I am running into is as soon as I run the linux install > program for it, it hardlocks a little after extracting and loading > the program. Well was messing more with it this weekend and found the following. The installer must be ran as root and one installed nvidia-settings needs ran first. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 07:29:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5A4716A41F; Mon, 7 Nov 2005 07:29:57 +0000 (GMT) (envelope-from nocool@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 076C443D55; Mon, 7 Nov 2005 07:29:54 +0000 (GMT) (envelope-from nocool@263.net) Received: from iscas-zfw728iit (smtp1 [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id E585B1187; Mon, 7 Nov 2005 15:29:55 +0800 (CST) (envelope-from nocool@263.net) X-Originating-IP: [159.226.5.225] Date: Mon, 7 Nov 2005 15:30:39 +0800 From: "nocool" To: "Robert Watson" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20051107072955.E585B1187@smtp.263.net> Cc: freebsd-hackers , freebsd-current Subject: Re: Why INVARIANTS option and sanity checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 07:29:58 -0000 >The design for FreeBSD calls for all memory and other resources provided >to unprivileged processes to be scrubbed before being made available. >Only using privilege should a process be able to gain access to unscrubbed >resources through allocation. For example: > >- When a process allocates a new file, it will be created as zero-length. > When extended using ftruncate(), any data read or pages mapped from the > file will be zero-filled. > >- When new memory is allocated to the process at time of exec(), using > brk(), or using anonymous mmap(), zero'd pages are provided to the > process (often optimized using copy-on-write). > I noticed the code for brk() and mmap() only set up the structure for addrees mapping, and the physical pages are allocated in vmfault(). I looked through the code of vmfault(), but I can't find the optimization of COW from zero's pages you mentioned. Can you give me some tips? Thanks. >- When kernel data structures are returned to user space, they are zero'd. > This is necessary even when a structure is filled out explicitly, as the > padding in the structure introduced by the compiler must also be zero'd. > For example, with data structures returned by ioctl(), sysctl(), etc. > I can't grasp your meaning. You mean to zero the structure before kernel filling it and copyouting it to the user space, or to zero after filling? I scan ioctl() and find the codes: { memp = malloc((u_long)size, M_IOCTLOPS, M_WAITOK); data = memp; ... if (com & IOC_OUT) { bzero(data, size); } ... error = fo_ioctl(fp, com, data, td->td_ucred, td); if (error == 0 && (com & IOC_OUT)) error = copyout(data, uap->data, (u_int)size); } These codes is consistent to my first understanding. Did you mean the same. But I really finds some codes not coincident with your answer, for example: In msgsnd(), message segments from msgpool[] are organised to form the message buffer, and kernel copy the user message into these buffer. And in msgrcv() the message are copyout to user area according the length strod in message header. There are not cleaning for these message segments in both functions. Can you give me some further explanation. Have a good weekend. Thanks From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:17:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 69E6D16A420; Mon, 7 Nov 2005 09:17:44 +0000 (GMT) In-Reply-To: <200511070044.jA70ioNQ012174@lorne.arm.org> from Derek Tattersall at "Nov 6, 2005 07:44:50 pm" To: dlt@mebtel.net Date: Mon, 7 Nov 2005 09:17:44 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051107091744.69E6D16A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: current@freebsd.org Subject: Re: Panic with GENERIC from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 09:17:44 -0000 > An i386 GENERIC kernel with an ndisgen'd wrapper for bcmwl5_sys driver > for a Linksys WPC54G panics as it attempts to DHCP. The back trace > reads (hand transcribed): > kdb_enter (c08y0b30) at kdb_enter + 0x2b > panic(c08773ef,c082441,0,d52bb944,c07daf6) at panic+0x127 > mb_free_ext(c3737e00) at mb_free_ext +0x185 > m_freem(c3737e00,c34d5cf8,0,c34e2800,c3737e00) at m_freem + 0x1a > ndis_rxeof(c34ec200,d511b9e8,1,c34fc7d4,d51bbb7e) at ndis_rxeof + 0xb9 > _end(c3785414,0,c34fc7d4,c34fc000,c34fc7d4)at 0xc333dd61 > BCMWL5_SYS_drv_data_start(c3652228,17,7a171200,d51bf098,0) at 0xc09ba8bb > BCMWL5_SYS_drv_data_start() at BCMWL5_SYS_drv_data_start + 0x3110 You know, I'm constantly amazed just how many ways people find to mess up a simple thing like sending in a bug report. You went to so much trouble to emphasize that your system panicked, and you were dilligent enough to copy down the stack trace. And then you went and forgot to tell us what the panic message said. Go back and repeat the crash and make a note of the actual panic message this time (i.e. "panic: something bad happened!"). Please note that "I don't remember" or "I'll get around to it later" are not valid responses. > A GENERIC kernel from a week ago with an ndisgen'd wrapper for the > same driver works fine. > > Di I cvsup in the middle of a commit? I noticed Bill had committed > some changes to the NDIS later later this afternoon, but they appeared > to be for an intel driver. More than likely this is the result of Andre's recent changes to the mbuf code. The NDISulator is still working fine for me with 6.x. When you report the full panic message so that I can tell what actually went wrong, I may be able to tell you more. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:20:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BEFB16A41F; Mon, 7 Nov 2005 09:20:14 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D0043D46; Mon, 7 Nov 2005 09:20:13 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from maverick.trit.org (maverick.trit.org [IPv6:2001:4830:2381:2062:212:f0ff:fe4c:896a]) by charade.trit.org (Postfix) with ESMTP id CABCB1AF4D4; Mon, 7 Nov 2005 09:20:12 +0000 (UTC) Received: from maverick.trit.org (localhost [127.0.0.1]) by maverick.trit.org (8.13.4/8.13.4) with ESMTP id jA79KC7l001268; Mon, 7 Nov 2005 09:20:12 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by maverick.trit.org (8.13.4/8.13.4/Submit) id jA79KBrr001267; Mon, 7 Nov 2005 09:20:11 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: maverick.trit.org: dima set sender to dd@freebsd.org using -f Date: Mon, 7 Nov 2005 09:20:11 +0000 From: Dima Dorfman To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051107092007.GA1240@trit.org> References: <20041116145445.EC71167E2B@gunfright.epcdirect.co.uk> <419B177D.2090206@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <419B177D.2090206@DeepCore.dk> X-PGP-Key: 69FAE582 (http://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: Marvell SATA Support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 09:20:14 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable S=F8ren Schmidt wrote: > Lawrence Farr wrote: > >Hello All, > > > >I have a Supermicro P4SCT+ with an onboard Marvell > >SATA controller, which also has the Adaptec Hostraid > >software raid functionality. Are there any patches to > >support the marvell controller as a plain controller > >anywhere? > > > >pciconf output if anyones interested: > > > >none4@pci2:4:0: class=3D0x010000 card=3D0x504111ab chip=3D0x504111ab rev= =3D0x03 > >hdr=3D0x00 > > vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device =3D '88SX504 4-port SATA I PCI-X Controller' > > class =3D mass storage > > subclass =3D SCSI >=20 > Not yet, but I'm working on it, actually on the exact same board. > Maybe, just maybe, you could hack the Highpoint hptmv driver, I havn't=20 > tried but unless they put in "tricks" to prohibit that it should work. S=F8ren, Have you made any progress on this? I have one of these chips on a SuperMicro 5013MT-MT(B) board. It has a HostRAID BIOS, but I don't need the RAID functionality--just being able to see the drives would be enough. Here's my pciconf output (I forgot to write down the entire class value and PCI address, but everything else is accurate): noneX@pciX:Y:Z: class=3DXXX card=3D0x518015d9 chip=3D0x504111ab rev=3D0x00= hdr=3D0x00 vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device =3D '88SX504 4-port SATA I PCI-X Controller' class =3D mass storage subclass =3D RAID Since the subclass is RAID, the ata driver doesn't try to attach to it at all--not even using generic DMA. Would it make sense to force it to try generic DMA, or does the subclass indicate that the interface is completely different? In its current state, I can't see any disks attached to this controller. Is there an easy way to make it work without RAID? I'd hate to put another controller into this box. Thanks, Dima. --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFDbxxGBzAFW2n65YIRAjTIAJ9CJiMYtp1w6yFkhBWRLADXYGI80ACgh05k DIP9smZ++jHtMUpNacm8+4U= =P8C+ -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 09:47:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 614BE16A41F for ; Mon, 7 Nov 2005 09:47:01 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0FB743D45 for ; Mon, 7 Nov 2005 09:47:00 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jA79kvQe023933 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Nov 2005 20:46:58 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jA79kuHh076509 for ; Mon, 7 Nov 2005 20:46:57 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jA79kuBq076508 for current@freebsd.org; Mon, 7 Nov 2005 20:46:56 +1100 (EST) (envelope-from pjeremy) Date: Mon, 7 Nov 2005 20:46:55 +1100 From: Peter Jeremy To: current@freebsd.org Message-ID: <20051107094655.GA76489@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: Subject: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 09:47:01 -0000 I (or my son, actually) just got bitten by the USB code trying to do bus_dmamem_alloc() in an interrupt handler and panicing when contigmalloc() tried to sleep. I've previously mentioned this bug in (eg) http://lists.freebsd.org/pipermail/freebsd-stable/2005-January/010979.html My son was trying to copy some photos onto a flashdisk at the time. Repeating the copy after the system recovered worked OK so the problem depends on how badly fragmented KVM is. Tonight's problem was in -CURRENT from last Saturday night. A backtrace is below. No crashdump (unfortunately) because the kernel got into a loop of breakpoint instruction faults. That said, the fault is fairly clearly the API bug that's mentioned in the above reference. Nov 7 19:14:26 server kernel: panic: trying to sleep while sleeping is prohibited Nov 7 19:14:26 server kernel: KDB: stack backtrace: Nov 7 19:14:26 server kernel: kdb_backtrace(c06fac04,c0762460,c06fd889,d4494828,100) at kdb_backtrace+0x2e Nov 7 19:14:26 server kernel: panic(c06fd889,1,c06fd805,10c,2) at panic+0xb7 Nov 7 19:14:26 server kernel: sleepq_add(cbe8f0e0,c07adc60,c070d2f1,0,c053527a) at sleepq_add+0xb2 Nov 7 19:14:26 server kernel: msleep(cbe8f0e0,c07adc60,44,c070d2f1,0) at msleep+0x2df Nov 7 19:14:26 server kernel: bwait(cbe8f0e0,44,c070d2f1,509,0) at bwait+0x60 Nov 7 19:14:26 server kernel: swap_pager_putpages(c2215ce4,d4494970,1,1,d4494920) at swap_pager_putpages+0x47a Nov 7 19:14:26 server kernel: default_pager_putpages(c2215ce4,d4494970,1,1,d4494920) at default_pager_putpages+0x2e Nov 7 19:14:26 server kernel: vm_pageout_flush(d4494970,1,1,60,c19115a0) at vm_pageout_flush+0x16b Nov 7 19:14:26 server kernel: vm_contig_launder_page(c1911558,0,c070dd4b,1ec,ffffffff) at vm_contig_launder_page+0x229 Nov 7 19:14:26 server kernel: vm_page_alloc_contig(10,0,0,ffffffff,1) at vm_page_alloc_contig+0x24d Nov 7 19:14:26 server kernel: contigmalloc(10000,c073a940,1,0,ffffffff) at contigmalloc+0xb5 Nov 7 19:14:26 server kernel: bus_dmamem_alloc(c2879100,c2410c88,5,c2410c84,ffffffff) at bus_dmamem_alloc+0xd2 Nov 7 19:14:26 server kernel: usb_block_allocmem(0,10000,1,c1fe333c,d4494a9c) at usb_block_allocmem+0x180 Nov 7 19:14:26 server kernel: usb_allocmem(c1b14000,10000,0,c1fe333c,d4494ae8) at usb_allocmem+0x73 Nov 7 19:14:26 server kernel: uhci_allocm(c1b14000,c1fe333c,10000,10c,1) at uhci_allocm+0x27 Nov 7 19:14:26 server kernel: usbd_transfer(c1fe3300,c4849480,c26e6400,d1483000,10000) at usbd_transfer+0xaa Nov 7 19:14:26 server kernel: umass_setup_transfer(c26e6400,c4849480,d1483000,10000,0) at umass_setup_transfer+0x57 Nov 7 19:14:26 server kernel: umass_bbb_state(c1a52d00,c26e6400,0,c19566f0,d4494b7c) at umass_bbb_state+0x1ce Nov 7 19:14:26 server kernel: usb_transfer_complete(c1a52d00,c053552c,c0761ce0,1,c06f9a88) at usb_transfer_complete+0x1aa Nov 7 19:14:26 server kernel: uhci_idone(c1a52d70,c1a52d88,c07ad548) at uhci_idone+0x2ee Nov 7 19:14:26 server kernel: uhci_check_intr(c1b14000,c1a52d70,c0761d20,c1b14000,1) at uhci_check_intr+0x148 Nov 7 19:14:26 server kernel: uhci_softintr(c1b14000,c0761d20) at uhci_softintr+0x57 Nov 7 19:14:26 server kernel: usb_schedsoftintr(c1b14000,c0761d20,c1b14000,c1987800,c1b0a200) at usb_schedsoftintr+0x39 Nov 7 19:14:26 server kernel: uhci_intr1(c1b14000) at uhci_intr1+0x248 Nov 7 19:14:26 server kernel: uhci_intr(c1b14000,0,c06f7c83,295,1) at uhci_intr+0x46 Nov 7 19:14:26 server kernel: ithread_execute_handlers(c1a28224,c1987800,c06f7c83,2f9,c198b180) at ithread_execute_handlers+0x118 Nov 7 19:14:26 server kernel: ithread_loop(c1a5f7f0,d4494d38,c06f7a7d,30d,c1a5f7f0) at ithread_loop+0x7b Nov 7 19:14:26 server kernel: fork_exit(c05278d0,c1a5f7f0,d4494d38) at fork_exit+0xc3 Nov 7 19:14:26 server kernel: fork_trampoline() at fork_trampoline+0x8 Nov 7 19:14:26 server kernel: --- trap 0x1, eip = 0, esp = 0xd4494d6c, ebp = 0 --- -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 11:21:24 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AAC16A41F; Mon, 7 Nov 2005 11:21:24 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from bombadil.mebtel.net (bombadil.mebtel.net [64.40.67.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 997AB43D46; Mon, 7 Nov 2005 11:21:23 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from localhost (localhost [127.0.0.1]) by bombadil.mebtel.net (Postfix) with ESMTP id 98D19123F2; Mon, 7 Nov 2005 06:21:22 -0500 (EST) Received: from bombadil.mebtel.net ([127.0.0.1]) by localhost (bombadil [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28323-09; Mon, 7 Nov 2005 06:21:22 -0500 (EST) Received: from lorne.arm.org (66-79-79-177.dsl.mebtel.net [66.79.79.177]) by bombadil.mebtel.net (Postfix) with ESMTP id DC26B12349; Mon, 7 Nov 2005 06:21:21 -0500 (EST) Received: from lorne.arm.org (localhost [127.0.0.1]) by lorne.arm.org (8.13.4/8.13.4) with ESMTP id jA7BLLq2014350; Mon, 7 Nov 2005 06:21:21 -0500 (EST) (envelope-from dlt@lorne.arm.org) Received: (from dlt@localhost) by lorne.arm.org (8.13.4/8.13.4/Submit) id jA7BLLNG014349; Mon, 7 Nov 2005 06:21:21 -0500 (EST) (envelope-from dlt) Date: Mon, 7 Nov 2005 06:21:21 -0500 From: Derek Tattersall To: Bill Paul Message-ID: <20051107112121.GA13870@lorne.arm.org> References: <200511070044.jA70ioNQ012174@lorne.arm.org> <20051107091744.69E6D16A420@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107091744.69E6D16A420@hub.freebsd.org> User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Virus-Scanned: by amavisd-new at mebtel.net Cc: freebsd-current@FreeBSD.ORG Subject: Re: Panic with GENERIC from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 11:21:24 -0000 * Bill Paul [051107 06:13]: > > An i386 GENERIC kernel with an ndisgen'd wrapper for bcmwl5_sys driver > > for a Linksys WPC54G panics as it attempts to DHCP. The back trace > > reads (hand transcribed): > > kdb_enter (c08y0b30) at kdb_enter + 0x2b > > panic(c08773ef,c082441,0,d52bb944,c07daf6) at panic+0x127 > > mb_free_ext(c3737e00) at mb_free_ext +0x185 > > m_freem(c3737e00,c34d5cf8,0,c34e2800,c3737e00) at m_freem + 0x1a > > ndis_rxeof(c34ec200,d511b9e8,1,c34fc7d4,d51bbb7e) at ndis_rxeof + 0xb9 > > _end(c3785414,0,c34fc7d4,c34fc000,c34fc7d4)at 0xc333dd61 > > BCMWL5_SYS_drv_data_start(c3652228,17,7a171200,d51bf098,0) at 0xc09ba8bb > > BCMWL5_SYS_drv_data_start() at BCMWL5_SYS_drv_data_start + 0x3110 > > You know, I'm constantly amazed just how many ways people find to > mess up a simple thing like sending in a bug report. You went to > so much trouble to emphasize that your system panicked, and you were > dilligent enough to copy down the stack trace. > > And then you went and forgot to tell us what the panic message said. Oops! Message is: NDIS0 Link state changed to Up panic mb_free_ext: unknown ext type CPUID = 0 > > Go back and repeat the crash and make a note of the actual panic > message this time (i.e. "panic: something bad happened!"). Please > note that "I don't remember" or "I'll get around to it later" are > not valid responses. > > > A GENERIC kernel from a week ago with an ndisgen'd wrapper for the > > same driver works fine. > > > > Di I cvsup in the middle of a commit? I noticed Bill had committed > > some changes to the NDIS later later this afternoon, but they appeared > > to be for an intel driver. > > More than likely this is the result of Andre's recent changes to > the mbuf code. The NDISulator is still working fine for me with 6.x. > > When you report the full panic message so that I can tell what > actually went wrong, I may be able to tell you more. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= Thanks for looking at this. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 12:08:57 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973D216A41F; Mon, 7 Nov 2005 12:08:57 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A1C443D46; Mon, 7 Nov 2005 12:08:56 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id jA7C8jd7025898; Mon, 7 Nov 2005 13:08:45 +0100 (CET) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <20051107092007.GA1240@trit.org> References: <20041116145445.EC71167E2B@gunfright.epcdirect.co.uk> <419B177D.2090206@DeepCore.dk> <20051107092007.GA1240@trit.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 7 Nov 2005 13:08:51 +0100 To: Dima Dorfman X-Mailer: Apple Mail (2.746.2) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: current@FreeBSD.ORG Subject: Re: Marvell SATA Support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 12:08:57 -0000 On 07/11/2005, at 10:20, Dima Dorfman wrote: > S=F8ren Schmidt wrote: >> Lawrence Farr wrote: >>> Hello All, >>> >>> I have a Supermicro P4SCT+ with an onboard Marvell >>> SATA controller, which also has the Adaptec Hostraid >>> software raid functionality. Are there any patches to >>> support the marvell controller as a plain controller >>> anywhere? >>> >>> pciconf output if anyones interested: >>> >>> none4@pci2:4:0: class=3D0x010000 card=3D0x504111ab chip=3D0x504111ab = =20 >>> rev=3D0x03 >>> hdr=3D0x00 >>> vendor =3D 'Marvell Semiconductor (Was: Galileo Technology = Ltd)' >>> device =3D '88SX504 4-port SATA I PCI-X Controller' >>> class =3D mass storage >>> subclass =3D SCSI >> >> Not yet, but I'm working on it, actually on the exact same board. >> Maybe, just maybe, you could hack the Highpoint hptmv driver, I =20 >> havn't >> tried but unless they put in "tricks" to prohibit that it should =20 >> work. > > S=F8ren, > > Have you made any progress on this? I have one of these chips on a > SuperMicro 5013MT-MT(B) board. It has a HostRAID BIOS, but I don't > need the RAID functionality--just being able to see the drives would > be enough. > > Here's my pciconf output (I forgot to write down the entire class > value and PCI address, but everything else is accurate): > > noneX@pciX:Y:Z: class=3DXXX card=3D0x518015d9 chip=3D0x504111ab = rev=3D0x00 =20 > hdr=3D0x00 > vendor =3D 'Marvell Semiconductor (Was: Galileo Technology = Ltd)' > device =3D '88SX504 4-port SATA I PCI-X Controller' > class =3D mass storage > subclass =3D RAID > > Since the subclass is RAID, the ata driver doesn't try to attach to it > at all--not even using generic DMA. Would it make sense to force it to > try generic DMA, or does the subclass indicate that the interface is > completely different? > > In its current state, I can't see any disks attached to this > controller. Is there an easy way to make it work without RAID? I'd > hate to put another controller into this box. The marvell chips doesn't look like a normal ATA controller *at all*, =20= they are very different animals that actually could be dealt with in =20 a seperate driver if need be. Now I've gone to great lengths in ATA to be able to support chips =20 like this (newer Promise chips and AHCI are also in this category), =20 and support will come at some point, I just havn't had time to work =20 on it due to other more urgent things (like getting ATA in 6.0 =20 working as well as possible). Since this is all spare time work I =20 have to prioritize my time, and so far there's always been something =20 else that popped up.. So patience is the way to go, or maybe hope for some vendor needing =20 it badly enough to contract me working hours to do it... S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 10:42:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB32E16A41F; Mon, 7 Nov 2005 10:41:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E86D43D46; Mon, 7 Nov 2005 10:41:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 0E8CCF2447; Mon, 7 Nov 2005 02:41:59 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00820-01; Mon, 7 Nov 2005 02:41:58 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 062A8F23D9; Mon, 7 Nov 2005 02:41:58 -0800 (PST) From: Sean McNeil To: SUZUKI Shinsuke In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Mon, 07 Nov 2005 02:39:27 -0800 Message-Id: <1131359967.1874.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Mon, 07 Nov 2005 12:25:06 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 10:42:00 -0000 On Sun, 2005-11-06 at 18:06 +0900, SUZUKI Shinsuke wrote: > Hello Sean, > > >>>>> On Sat, 5 Nov 2005 14:39:13 -0800 > >>>>> sean@mcneil.com(Sean McNeil) said: > > > > sean> ping6 does NOT work for > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > sean> 2002:18c7:2d36:: > > > > > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > > > see an error message from your kernel like following? > > > dc0: possible hardware address duplication detected, disable IPv6 > > No, nothing like that in any logs. I can't see how there could > > suddenly be a duplication of hardware addresses. I agree, though, > > that IPv6 is disabled for dc0. Some change in the kernel has caused > > this. > > I tried the same configuration (with the different interface card) > using the latest RELENG-6 in my environment, but I couldn't reproduce > your problem. > > So could you please show me the result of the following commands? > - netstat -rnf inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2002:c058:6301:: UGS stf0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2002::/24 ::1 UGRS lo0 => 2002::/16 2002:18c7:2d36::1 U stf0 2002:18c7:2d36:: 00:03:6d:1a:b1:9b UHL lo0 => 2002:18c7:2d36::/64 link#2 UC dc0 2002:18c7:2d36::1 link#5 UHL lo0 2002:18c7:2d36:0:203:6dff:fe1a:b19b 00:03:6d:1a:b1:9b UHL lo0 2002:18c7:2d36:1:: 00:14:85:85:27:b3 UHL lo0 => 2002:18c7:2d36:1::/64 link#3 UC sk0 2002:18c7:2d36:1:214:85ff:fe85:27b3 00:14:85:85:27:b3 UHL lo0 2002:7f00::/24 ::1 UGRS lo0 2002:e000::/20 ::1 UGRS lo0 2002:ff00::/24 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%fwe0/64 link#1 UC fwe0 fe80::11:6ff:fe00:7568%fwe0 02:11:06:00:75:68 UHL lo0 fe80::%dc0/64 link#2 UC dc0 fe80::203:6dff:fe1a:b19b%dc0 00:03:6d:1a:b1:9b UHL lo0 fe80::%sk0/64 link#3 UC sk0 fe80::214:85ff:fe85:27b3%sk0 00:14:85:85:27:b3 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:1::/32 link#1 UC fwe0 ff01:2::/32 link#2 UC dc0 ff01:3::/32 link#3 UC sk0 ff01:4::/32 ::1 UC lo0 ff02::/16 ::1 UGRS lo0 ff02::%fwe0/32 link#1 UC fwe0 ff02::%dc0/32 link#2 UC dc0 ff02::%sk0/32 link#3 UC sk0 ff02::%lo0/32 ::1 UC lo0 > - ndp -i dc0 linkmtu=1500, maxmtu=1500, curhlim=64, basereachable=30s0ms, reachable=44s, retrans=1s0ms Flags: nud accept_rtadv > - ndp -na Neighbor Linklayer Address Netif Expire S Flags 2002:18c7:2d36:: 0:3:6d:1a:b1:9b dc0 permanent R 2002:18c7:2d36::1 (incomplete) stf0 permanent R 2002:18c7:2d36:0:203:6dff:fe1a:b19b 0:3:6d:1a:b1:9b dc0 permanent R 2002:18c7:2d36:1:: 0:14:85:85:27:b3 sk0 permanent R 2002:18c7:2d36:1:214:85ff:fe85:27b3 0:14:85:85:27:b3 sk0 permanent R fe80::11:6ff:fe00:7568%fwe0 2:11:6:0:75:68 fwe0 permanent R fe80::203:6dff:fe1a:b19b%dc0 0:3:6d:1a:b1:9b dc0 permanent R fe80::214:85ff:fe85:27b3%sk0 0:14:85:85:27:b3 sk0 permanent R fe80::1%lo0 (incomplete) lo0 permanent R > - kernel log message after sysctl -w net.inet6.icmp6.nd6_debug=1 > (if exists) net.inet6.icmp6.nd6_debug: 0 -> 1 Then I tried a ping6. Nothing from the ping6 or any log messages. Some additional info: server# sysctl -a | grep inet net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 700 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 0 net.inet.ip.dummynet.searches: 0 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 0 net.inet.ip.dummynet.curr_time: 1636813 net.inet.ip.dummynet.hash_size: 64 net.inet.ip.fastforwarding: 0 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 21 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 251 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.maxfragpackets: 800 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 4 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 159 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.minmssoverload: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies: 1 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 3 net.inet.tcp.msl: 30000 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.strict_mcast_mship: 0 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.raw.recvspace: 8192 net.inet.raw.maxdgram: 8192 net.inet.accf.unloadable: 0 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 0 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.max_age: 1200 net.link.ether.inet.prune_intvl: 300 net.inet6.ip6.forwarding: 1 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 50 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: 20010528/FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 0 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.fw.deny_unknown_exthdrs: 1 net.inet6.ip6.fw.enable: 1 net.inet6.ip6.fw.debug: 1 net.inet6.ip6.fw.verbose: 0 net.inet6.ip6.fw.verbose_limit: 0 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 1 > > Two things to note: > > The dc0 interface has option VLAN_MTU. Don't know why. > > The dc0 interface is my gateway with ipv4mapping. > > At least these two does not seem to be relating to this problem. > > Thanks, > ---- > SUZUKI, Shinsuke @ KAME Project > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 10:53:36 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E76516A41F; Mon, 7 Nov 2005 10:53:36 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA03B43D4C; Mon, 7 Nov 2005 10:53:35 +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 78F71F24CA; Mon, 7 Nov 2005 02:53:35 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00800-01; Mon, 7 Nov 2005 02:53:33 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 6689CF24C6; Mon, 7 Nov 2005 02:53:33 -0800 (PST) From: Sean McNeil To: SUZUKI Shinsuke In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Mon, 07 Nov 2005 02:53:33 -0800 Message-Id: <1131360813.1346.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Mon, 07 Nov 2005 12:25:06 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 10:53:36 -0000 On Sun, 2005-11-06 at 18:06 +0900, SUZUKI Shinsuke wrote: > Hello Sean, > > >>>>> On Sat, 5 Nov 2005 14:39:13 -0800 > >>>>> sean@mcneil.com(Sean McNeil) said: > > > > sean> ping6 does NOT work for > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > sean> 2002:18c7:2d36:: > > > > > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > > > see an error message from your kernel like following? > > > dc0: possible hardware address duplication detected, disable IPv6 > > No, nothing like that in any logs. I can't see how there could > > suddenly be a duplication of hardware addresses. I agree, though, > > that IPv6 is disabled for dc0. Some change in the kernel has caused > > this. > > I tried the same configuration (with the different interface card) > using the latest RELENG-6 in my environment, but I couldn't reproduce > your problem. With a kernel built just moments ago, I still have the same issue. I have an older kernel, however, that works perfectly fine: FreeBSD server.mcneil.com 6.0-STABLE FreeBSD 6.0-STABLE #78: Tue Nov 1 23:07:02 PST 2005 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 amd64 With this kernel I can ping6 my dc0 interface just fine. That should help narrow things down a bit. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 12:57:31 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AC5416A41F; Mon, 7 Nov 2005 12:57:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2C7343D48; Mon, 7 Nov 2005 12:57:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jA7CvTUJ093414; Mon, 7 Nov 2005 07:57:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id jA7CvSsv021832; Mon, 7 Nov 2005 07:57:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C7BBF7302F; Mon, 7 Nov 2005 07:57:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051107125728.C7BBF7302F@freebsd-current.sentex.ca> Date: Mon, 7 Nov 2005 07:57:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 12:57:31 -0000 TB --- 2005-11-07 11:26:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-07 11:26:10 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-11-07 11:26:10 - cleaning the object tree TB --- 2005-11-07 11:26:39 - checking out the source tree TB --- 2005-11-07 11:26:39 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-11-07 11:26:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-07 11:33:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-07 11:33:26 - cd /src TB --- 2005-11-07 11:33:26 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-11-07 12:37:55 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-07 12:37:55 - cd /src TB --- 2005-11-07 12:37:55 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Nov 7 12:37:56 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Nov 7 12:51:58 UTC 2005 TB --- 2005-11-07 12:51:58 - generating LINT kernel config TB --- 2005-11-07 12:51:58 - cd /src/sys/alpha/conf TB --- 2005-11-07 12:51:58 - /usr/bin/make -B LINT TB --- 2005-11-07 12:51:58 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-07 12:51:58 - cd /src TB --- 2005-11-07 12:51:58 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 7 12:51:58 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:87: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:3:1: this is the location of the previous definition *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-07 12:57:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-07 12:57:28 - ERROR: failed to build lint kernel TB --- 2005-11-07 12:57:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 13:45:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 675AF16A421 for ; Mon, 7 Nov 2005 13:45:06 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 450B243D46 for ; Mon, 7 Nov 2005 13:45:05 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so388525wxc for ; Mon, 07 Nov 2005 05:45:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RMFbRzvCi89A9PmufWTUgXgtadr8pciazsvVeOlfOCOdWqmF9bfw+TyiaMUfCGtBIJqJ4cfJlPK9WKmPnI1nmphYpvz6tAE4vUTS46ZDFXtE4C2XFxWHyPgoSP08YC+sCwpuqx8PzNUb5lyrkEaET7x9FG2mnqJqh3tKmujYaVE= Received: by 10.70.96.6 with SMTP id t6mr267247wxb; Mon, 07 Nov 2005 05:45:04 -0800 (PST) Received: by 10.70.105.13 with HTTP; Mon, 7 Nov 2005 05:45:04 -0800 (PST) Message-ID: <84dead720511070545i4c585f4bt600af50776d1a458@mail.gmail.com> Date: Mon, 7 Nov 2005 19:15:04 +0530 From: Joseph Koshy To: John Baldwin In-Reply-To: <200511061012.57212.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051027233636.GA39380@dmw.hopto.org> <200511061012.57212.jhb@FreeBSD.org> Cc: freebsd-net@freebsd.org, Vaibhave Agarwal , current@freebsd.org, chris@gnome.co.uk, chmr@edvz.tu-graz.ac.at Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 13:45:06 -0000 >>>> "jb" =3D=3D "John Baldwin" said: jb> We don't detect the local APIC via MSR's or the APIC bit in jb> cpu_features, but rely on a working MP Table or MADT table jb> to setup both the local APIC(s) and I/O APIC(s). Unfortunately not having the APIC enabled in the BIOS also means that we cannot use PMCs, the APIC timer or the thermal monitor, even if the CPU implements these features. My too simple experiment attempting to enable the local APIC on an AMD K7 box didn't go very well; this would be entirely due to lack of clue on my part since Linux 2.4 seems to be able to turn on the APIC on the same hardware without issues. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 14:19:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0C1A16A41F for ; Mon, 7 Nov 2005 14:19:38 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 508CA43D4C for ; Mon, 7 Nov 2005 14:19:38 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id AEA3A523A5; Mon, 7 Nov 2005 15:19:34 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 57C98405A; Mon, 7 Nov 2005 15:19:11 +0100 (CET) Date: Mon, 7 Nov 2005 15:19:11 +0100 From: Jeremie Le Hen To: Gavin Atkinson Message-ID: <20051107141911.GA1067@obiwan.tataz.chchile.org> References: <1130943516.51544.34.camel@buffy.york.ac.uk> <20051102152322.GF93549@cicely12.cicely.de> <1130945849.51544.42.camel@buffy.york.ac.uk> <20051102154552.GE32554@pleiades.aeternal.net> <1130954841.51544.57.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1130954841.51544.57.camel@buffy.york.ac.uk> User-Agent: Mutt/1.5.10i Cc: Martin Hudec , freebsd-current@freebsd.org Subject: Re: Poor NFS server performance in 6.0 with SMP and mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 14:19:39 -0000 Hi, Gavin, Martin, > Certainly. For heavily loaded machines, polling seems to significantly > improve performance, but in my experience on lightly loaded machines it > seems to increase latency on response to packets. For the particular > workloads it will be used for, (serving web content and databases), the > latency can be noticeable. > > IMHO, polling is great for lower-spec boxes or highly loaded machines, > but can hinder performance when the machine is lightly loaded. I have a > few machines which run with polling on, and for those usage patterns it > really helps. I just don't believe this is one of those cases. Just FYI, em(4) has powerful thresholds managements concerning what Intel calls "interrupt moderation". This is plainly described in this document (quite short to read) [1]. This looks like software polling except this is managed by the network adapter itself. Basically, em(4) network adapters have an "absolute timer" which achieves, IIUC, the same goal as our software polling : when the timer reaches zero, the adapter generates an interrupt. But those adapters also have a "packet timer", and this is very interesting and just impossible to emulate this behaviour with software polling. A packet timer is shorter than an absolute timer in order to decrease latency : when a packet is received the packet timer countdown begins. If another packet is received before it reaches zero, it is reset but goes on couting down... and so on, until one of the absolute timer or the packet timer timeouts. (I hope I'm clear enough). This allows to have the benefits of polling (limiting the interrupt rate) without having the latency introduced by software polling. AFAIK, this is tunable through these sysctls : % obiwan:gogo# sysctl dev.em.0 | grep delay % dev.em.0.rx_int_delay: 0 % dev.em.0.tx_int_delay: 66 % dev.em.0.rx_abs_int_delay: 66 % dev.em.0.tx_abs_int_delay: 66 Note that the packet timer is useless here. BTW, given the above feature, is there any benefits to use software polling of em(4) chips ? Best regards, [1] http://www.intel.com/design/network/applnots/ap450.pdf -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 14:31:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A23916A41F for ; Mon, 7 Nov 2005 14:31:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4AE43D49 for ; Mon, 7 Nov 2005 14:31:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 28C0646B7E; Mon, 7 Nov 2005 09:31:12 -0500 (EST) Date: Mon, 7 Nov 2005 14:31:12 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeremie Le Hen In-Reply-To: <20051003115659.GJ43195@obiwan.tataz.chchile.org> Message-ID: <20051107142621.Q9690@fledge.watson.org> References: <433E9C4F.8040404@charter.net> <20051002124424.D71864@fledge.watson.org> <20051003115659.GJ43195@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andrew Lankford , current@freebsd.org Subject: Re: RELENG_6 Kernel doesn't build due to DEVFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 14:31:13 -0000 On Mon, 3 Oct 2005, Jeremie Le Hen wrote: > Hi Andrew, Robert, > >>> I haven't been able to build a GENERIC 6.0 kernel on amd64 for about a week >>> now because of this error: >> >> Make sure you buildworld before buildkernel, there was a compiler tweak, >> and the new compiler version is required to build the new kernel. > > I've run into this too, because I used to compile my kernel manually > (the old way). This method will indeed use the old compiler, thus you > will need to use the buildkernel target. > > Robert, FWIW, what was the compiler tweak you are talking about ? Sorry about the delay in responding to this, just found your e-mail while starting to catch up on some older ones. The tweak below fixes a bug in which valid syntax was not accepted by the computer. This was followed by several commits that introduced that valid syntax into the source tree, meaning that the tree would not build with an older compiler due to the older compiler incorrectly rejecting it as invalid. Ideally, commits to update the compiler are made, and then after some longish delay (a few weeks), the source code is updated to make use of new compiler features. In this case, the changes came in close proximity, resulting in a few more stubbed toes. obrien 2005-09-07 09:23:39 UTC FreeBSD src repository Modified files: contrib/gcc c-decl.c Log: Fix bug where static forward declarations weren't accepted. This allows us to fix non-ISO-C constructs in our kernel to legal ISO-C. Submitted by: rodrigc Obtained from: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00006.html Revision Changes Path 1.13 +5 -2 src/contrib/gcc/c-decl.c Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 14:57:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF56116A41F; Mon, 7 Nov 2005 14:57:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6994543D45; Mon, 7 Nov 2005 14:57:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jA7EvKve007241; Mon, 7 Nov 2005 09:57:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA7EvK9u066025; Mon, 7 Nov 2005 09:57:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 271ED7302F; Mon, 7 Nov 2005 09:57:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051107145720.271ED7302F@freebsd-current.sentex.ca> Date: Mon, 7 Nov 2005 09:57:20 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 14:57:22 -0000 TB --- 2005-11-07 12:57:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-07 12:57:28 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-11-07 12:57:28 - cleaning the object tree TB --- 2005-11-07 12:58:07 - checking out the source tree TB --- 2005-11-07 12:58:07 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-11-07 12:58:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-07 13:04:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-07 13:04:55 - cd /src TB --- 2005-11-07 13:04:55 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-11-07 14:34:46 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-07 14:34:46 - cd /src TB --- 2005-11-07 14:34:46 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Nov 7 14:34:46 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Nov 7 14:51:07 UTC 2005 TB --- 2005-11-07 14:51:07 - generating LINT kernel config TB --- 2005-11-07 14:51:07 - cd /src/sys/amd64/conf TB --- 2005-11-07 14:51:07 - /usr/bin/make -B LINT TB --- 2005-11-07 14:51:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-07 14:51:07 - cd /src TB --- 2005-11-07 14:51:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 7 14:51:07 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/ppi.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/puc/puc.c In file included from /src/sys/dev/puc/puc.c:87: ./opt_puc.h:1:1: "PUC_FASTINTR" redefined /src/sys/dev/puc/puc.c:3:1: this is the location of the previous definition *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-07 14:57:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-07 14:57:19 - ERROR: failed to build lint kernel TB --- 2005-11-07 14:57:19 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 16:18:59 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B882916A420; Mon, 7 Nov 2005 16:18:59 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAA5A43D86; Mon, 7 Nov 2005 16:18:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1523317 for multiple; Mon, 07 Nov 2005 11:20:40 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7GIXrN011431; Mon, 7 Nov 2005 11:18:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Mon, 7 Nov 2005 11:05:56 -0500 User-Agent: KMail/1.8.2 References: <20051027233636.GA39380@dmw.hopto.org> <436E874E.4010305@root.org> In-Reply-To: <436E874E.4010305@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071105.58729.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: freebsd-net@freebsd.org, Vaibhave Agarwal , current@freebsd.org, chris@gnome.co.uk, Nate Lawson Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 16:19:00 -0000 On Sunday 06 November 2005 05:44 pm, Nate Lawson wrote: > Vaibhave Agarwal wrote: > > On Sun, 6 Nov 2005, John Baldwin wrote: > >>We don't detect the local APIC via MSR's or the APIC bit in cpu_features, > >> but rely on a working MP Table or MADT table to setup both the local > >> APIC(s) and I/O APIC(s). Does your machine have a valid MP Table or an > >> APIC table in its acpidump? Many UP machine BIOSes don't include those > >> tables. > > > > I think you are right. > > There is no valid APIC table in the acpidump. > > The only place where APIC is mentioned in the acpidump(8) is in > > following: > > > > Scope (\_SB) > > { > > Name (APIC, 0x00) > > Method (_PIC, 1, NotSerialized) > > { > > Store (Arg0, APIC) > > } > > } > > > > > > And I suppose APIC is disabled in the BIOS too. > > Is there a way to enable APIC using software, without changing the BIOS, > > since I dont have access to the BIOS, as it is a remote machine (with > > root access) ? > > The above references to APIC just store a value in a convenience > variable. If there's nothing else in the AML that references the > \_SB.APIC variable, then it has no effect on the system. In that case, > the only way to get APIC support on that machine is to implement another > way of enumerating it. And even then it can't be used for any device interrupts since there aren't any I/O APICs. On a UP machine without I/O APICs, it's actually probably more optimal to just use irq0 and irq8 for clocks rather than the lapic timer anyway. The only real possible gain is the ability to use the profiling interrupt from the local APIC. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 16:27:27 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F06D816A41F for ; Mon, 7 Nov 2005 16:27:27 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8987243D45 for ; Mon, 7 Nov 2005 16:27:27 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id jA7GaXYU054586; Mon, 7 Nov 2005 11:36:33 -0500 (EST) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 7 Nov 2005 11:27:03 -0500 User-Agent: KMail/1.6.2 References: <20051105184341.45112.qmail@istanbul.enderunix.org> In-Reply-To: <20051105184341.45112.qmail@istanbul.enderunix.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511071127.05206.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1165/Sun Nov 6 00:12:58 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Baris Simsek Subject: Re: FreeBSD 6.0 Released: problem with HP Pavillion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 16:27:28 -0000 On Saturday 05 November 2005 01:43 pm, Baris Simsek wrote: > hello, > > Unfortunately i couldn't booted with any version of FreeBSD on HP > pavillion zv5000 notebook. same result with FreeBSD 6.0 > > It always reboots while loading kernel. > > I tried latest NetBSD and it also have same problem. I'll try also > OpenBSD to make sure about if it is connected to *BSD. > > 1 hour ago i installed OpenSolaris, and there is no problem. I > installed linux before on it without any problem. > > I tried some boot options such as disabling ACPI. but it didn't > effect. Sorry i don't have more details because it goes reboot when > start to load kernel. May be, i should make kernel hacking, if i > can do. > > I just want to know that, is there anybody has same problem, or is > there anybody using FreeBSD on HP Pavilion? > > Although, thanks for your efforts to release FreeBSD 6. I hope i'll > solve some performance problems (for example MySQL performance > problem in 4.X discussed here before) > > regards, You may have to try this: http://docs.freebsd.org/cgi/mid.cgi?2fd864e050323231774aa75cc Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 16:50:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD64D16A41F for ; Mon, 7 Nov 2005 16:50:54 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE11A43D53 for ; Mon, 7 Nov 2005 16:50:50 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 07 Nov 2005 08:50:49 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jA7Gon4P075822; Mon, 7 Nov 2005 08:50:49 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jA7Gon76075821; Mon, 7 Nov 2005 08:50:49 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200511071650.jA7Gon76075821@ambrisko.com> In-Reply-To: <200511050045.50215.Peter_Losher@isc.org> To: Peter Losher Date: Mon, 7 Nov 2005 08:50:49 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org, "Lynn A. Roth" Subject: Re: Problems Installing to PowerEdge 850 with SATA Drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 16:50:54 -0000 Peter Losher writes: | On Thursday 03 November 2005 02:22 pm, Doug Ambrisko wrote: | | > I can confirm the problem on the PE850. I have it working with my | > latest 4.X SATA patches (which I haven't published yet). I might | > be able to look into this. | | Curious - does this also happen w/ 5.4? | | Best Wishes - Peter | (who has some PE850's coming his way, so is a interested party) I think 5.4 is going to have more problems in general since I don't think it knows anything about AHCI. I think I might be able to make a hack to 6/-current to make hybrid work. However, Soren needs to figure away to deal with this. He might already have some ideas. Also I'm not sure how much awareness 5.4 has of ICH6/7. Doug A. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 17:20:03 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 4D17016A420; Mon, 7 Nov 2005 17:20:03 +0000 (GMT) In-Reply-To: <20051107112121.GA13870@lorne.arm.org> from Derek Tattersall at "Nov 7, 2005 06:21:21 am" To: dlt@mebtel.net Date: Mon, 7 Nov 2005 17:20:03 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051107172003.4D17016A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Panic with GENERIC from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 17:20:03 -0000 > * Bill Paul [051107 06:13]: > > > An i386 GENERIC kernel with an ndisgen'd wrapper for bcmwl5_sys driver > > > for a Linksys WPC54G panics as it attempts to DHCP. The back trace > > > reads (hand transcribed): > > > kdb_enter (c08y0b30) at kdb_enter + 0x2b > > > panic(c08773ef,c082441,0,d52bb944,c07daf6) at panic+0x127 > > > mb_free_ext(c3737e00) at mb_free_ext +0x185 > > > m_freem(c3737e00,c34d5cf8,0,c34e2800,c3737e00) at m_freem + 0x1a > > > ndis_rxeof(c34ec200,d511b9e8,1,c34fc7d4,d51bbb7e) at ndis_rxeof + 0xb9 > > > _end(c3785414,0,c34fc7d4,c34fc000,c34fc7d4)at 0xc333dd61 > > > BCMWL5_SYS_drv_data_start(c3652228,17,7a171200,d51bf098,0) at 0xc09ba8bb > > > BCMWL5_SYS_drv_data_start() at BCMWL5_SYS_drv_data_start + 0x3110 > > > > You know, I'm constantly amazed just how many ways people find to > > mess up a simple thing like sending in a bug report. You went to > > so much trouble to emphasize that your system panicked, and you were > > dilligent enough to copy down the stack trace. > > > > And then you went and forgot to tell us what the panic message said. > > Oops! Message is: > NDIS0 Link state changed to Up > panic mb_free_ext: unknown ext type > CPUID = 0 Aha, ok. I just committed a small change to ndis_var.h. Sync it and try again. Alternatively, if you need the NDIS interface, you can make this small change by hand: - Bring up ndis_var.h in your favorite editor. - Find the line that says: #define EXT_NDIS 0x999 - Change it to: #define EXT_NDIS EXT_NET_DRV - Recompile ndis.ko (specifically, kern_ndis.o) This is due to an API behavior change that was introduced with the latest mbuf code changes. It used to be you could call MEXTADD() to add buffers to an mbuf using an arbitrary type value, and ultimately they would be released correctly. Now, m_ext_free() will trigger a KASSERT() if it encounters an EXT_xxx type that isn't specifically defined in mbuf.h. This change to ndis_var.h gets around that for now, though in my opinion m_ext_free() should be modified to restore the old behavior, particularly since the way the code is structured now, if you build a non-debug kernel, you'll end up leaking the attached buffer instead of getting a panic. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:23:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 2D9CE16A420; Mon, 7 Nov 2005 18:23:38 +0000 (GMT) In-Reply-To: <1131359967.1874.6.camel@server.mcneil.com> from Sean McNeil at "Nov 7, 2005 02:39:27 am" To: sean@mcneil.com Date: Mon, 7 Nov 2005 18:23:38 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051107182338.2D9CE16A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 18:23:38 -0000 > On Sun, 2005-11-06 at 18:06 +0900, SUZUKI Shinsuke wrote: > > Hello Sean, > > > > >>>>> On Sat, 5 Nov 2005 14:39:13 -0800 > > >>>>> sean@mcneil.com(Sean McNeil) said: > > > > > > sean> ping6 does NOT work for > > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > > sean> 2002:18c7:2d36:: > > > > > > > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > > > > see an error message from your kernel like following? > > > > dc0: possible hardware address duplication detected, disable IPv6 > > > No, nothing like that in any logs. I can't see how there could > > > suddenly be a duplication of hardware addresses. I agree, though, > > > that IPv6 is disabled for dc0. Some change in the kernel has caused > > > this. > > > > I tried the same configuration (with the different interface card) > > using the latest RELENG-6 in my environment, but I couldn't reproduce > > your problem. In order to really duplicate his configuration, you would need to use the same network card. But of course you can't do that, because he never mentioned just what card he has. The dc(4) driver supports a whole bunch of different chips. It really really really matters that you tell us exactly which one you have. It would also really really help if you could run a packet dump on dc0 while trying to ping6 it from another host. You should do tcpdump -n -e -p -i dc0 so as not to force it into promisc mode. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 18:35:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5572B16A41F for ; Mon, 7 Nov 2005 18:35:20 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95BB543D49 for ; Mon, 7 Nov 2005 18:35:18 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 07 Nov 2005 10:35:17 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jA7IZHEo081506; Mon, 7 Nov 2005 10:35:17 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jA7IZHuV081505; Mon, 7 Nov 2005 10:35:17 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200511071835.jA7IZHuV081505@ambrisko.com> In-Reply-To: To: lynnr.junk@interactivefs.com Date: Mon, 7 Nov 2005 10:35:17 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Problems Installing to PowerEdge 850 with SATA Drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 18:35:20 -0000 Doug Ambrisko writes: | Doug Ambrisko writes: | | Lynn A. Roth writes: | | | I have two new Dell Poweredge 850 machines. They have an Intel ICH7 | | | chipset. When I boot FreeBSD 6 RC1, the controller is identified, but | | | any drives connected to the SATA ports are not detected. The drive that | | | is included with the system is a Seagate 7200.7 drive. I also tried a | | | Maxtor. | | | | I can confirm the problem on the PE850. I have it working with my | | latest 4.X SATA patches (which I haven't published yet). I might | | be able to look into this. | | | | FWIW, I my code these SATA registers in 4.X before the become alive: | | ata2: Intel SATA P0 status 0 error 4050000 scontrol 0 0 1 | | ata2: Intel SATA P0 status 113 error 4050000 scontrol 0 0 1 | | ata2: Intel SATA P0 status 113 error 0 scontrol 0 0 1 | | ata3: Intel SATA P1 status 0 error 4050000 scontrol 0 1 1 | | ata3: Intel SATA P1 status 113 error 4050000 scontrol 0 1 1 | | ata3: Intel SATA P1 status 113 error 0 scontrol 0 1 1 | | On other Intel controllers they I don't have to acknowledge the | | errors off the bat. | | This is sort-of the clue indirectly. The issue is that the ICH7 and | maybe ICH6 have a hybrid AHCI mode in which the SATA status, error, control | registers are present in AHCI for compatibility but that's all. The | reset of the AHCI registers are not there so then you have to | wack the registers in PCI space 0x92 to reset the controller. Doing | an AHCI reset won't work since it isn't running full AHCI mode. | | I don't have a fix but this is the problem that I see. If we don't | do the channel reset via PCI space then it can never get out of that | state so no drives are found. Here's a hack to make it work on PE850: Index: ata-chipset.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.136 diff -u -p -r1.136 ata-chipset.c --- ata-chipset.c 12 Oct 2005 20:00:26 -0000 1.136 +++ ata-chipset.c 7 Nov 2005 18:30:22 -0000 @@ -236,15 +236,35 @@ ata_sata_setmode(device_t dev, int mode) static int ata_sata_connect(struct ata_channel *ch) { - u_int32_t status; - int timeout; + u_int32_t status, error; + int timeout, device; + struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(ch->dev)); + int something_there = 0; + + if (ctlr->chip->chipid == ATA_I82801GB_S1) { + status = ATA_IDX_INL(ch, ATA_SSTATUS); + error = ATA_IDX_INL(ch, ATA_SERROR); + if (status == (ATA_SS_DET_DEV_PRESENT | ATA_SS_DET_PHY_OFFLINE) || + status == (ATA_SS_DET_PHY_ONLINE | ATA_SS_SPD_GEN1 | ATA_SS_IPM_ACTIVE)) { + /* reset port */ + device = 1 << (ch->unit + 1); + pci_write_config(ch->dev, 0x92, + pci_read_config(ch->dev, 0x92, 2) & ~device, 2); + pci_write_config(ch->dev, 0x92, + pci_read_config(ch->dev, 0x92, 2) & ~device, 2); + } + } /* wait up to 1 second for "connect well" */ for (timeout = 0; timeout < 100 ; timeout++) { status = ATA_IDX_INL(ch, ATA_SSTATUS); + error = ATA_IDX_INL(ch, ATA_SERROR); + ATA_IDX_OUTL(ch, ATA_SERROR, error); if ((status & ATA_SS_CONWELL_MASK) == ATA_SS_CONWELL_GEN1 || - (status & ATA_SS_CONWELL_MASK) == ATA_SS_CONWELL_GEN2) - break; + (status & ATA_SS_CONWELL_MASK) == ATA_SS_CONWELL_GEN2) { + something_there = 1; + break; + } ata_udelay(10000); } if (timeout >= 100) { @@ -267,7 +287,7 @@ ata_sata_connect(struct ata_channel *ch) } if (bootverbose) device_printf(ch->dev, "SATA connect ready time=%dms\n", timeout * 10); - if (timeout < 1000) { + if (something_there || timeout < 1000) { if ((ATA_IDX_INB(ch, ATA_CYL_LSB) == ATAPI_MAGIC_LSB) && (ATA_IDX_INB(ch, ATA_CYL_MSB) == ATAPI_MAGIC_MSB)) ch->devices = ATA_ATAPI_MASTER; @@ -1657,6 +1677,12 @@ ata_intel_chipinit(device_t dev) /* force all ports active "the legacy way" */ pci_write_config(dev, 0x92, pci_read_config(dev, 0x92, 2) | 0x0f,2); + if (ctlr->chip->chipid == ATA_I82801GB_S1) { + /* enable AHCI register compat mode */ + pci_write_config(dev, 0x94, pci_read_config(dev, 0x94, 4) | 1 << 9, 4); + ATA_OUTL(ctlr->r_res2, 0x0C, ATA_INL(ctlr->r_res2, 0x0C) | 0xf); + } + /* enable AHCI mode */ ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_AE); @@ -1845,10 +1871,13 @@ ata_intel_reset(device_t dev) struct ata_channel *ch = device_get_softc(dev); int mask, timeout; - /* ICH6 has 4 SATA ports as master/slave on 2 channels so deal with pairs */ + /* ICH6/7 has 4 SATA ports as master/slave on 2 channels so deal with pairs */ if (ctlr->chip->chipid == ATA_I82801FB_S1 || ctlr->chip->chipid == ATA_I82801FB_R1 || - ctlr->chip->chipid == ATA_I82801FB_M) { + ctlr->chip->chipid == ATA_I82801FB_M || + ctlr->chip->chipid == ATA_I82801GB_S1 || + ctlr->chip->chipid == ATA_I82801GB_R1 || + ctlr->chip->chipid == ATA_I82801GB_M) { mask = (0x0005 << ch->unit); } else { This works for me on my PE850. It shouldn't break other stuff etc. I assume the ICH6 will need the same type of change. Doug A. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:21:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BA116A420; Mon, 7 Nov 2005 19:21:01 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14C5B43D6B; Mon, 7 Nov 2005 19:21: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 B6A96F24CD; Mon, 7 Nov 2005 11:20:59 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00814-01; Mon, 7 Nov 2005 11:20:44 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0E7C5F21CB; Mon, 7 Nov 2005 11:20:44 -0800 (PST) From: Sean McNeil To: Bill Paul In-Reply-To: <20051107182338.2D9CE16A420@hub.freebsd.org> References: <20051107182338.2D9CE16A420@hub.freebsd.org> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Mon, 07 Nov 2005 11:20:43 -0800 Message-Id: <1131391243.1343.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Mon, 07 Nov 2005 19:28:59 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 19:21:01 -0000 On Mon, 2005-11-07 at 18:23 +0000, Bill Paul wrote: > > On Sun, 2005-11-06 at 18:06 +0900, SUZUKI Shinsuke wrote: > > > Hello Sean, > > > > > > >>>>> On Sat, 5 Nov 2005 14:39:13 -0800 > > > >>>>> sean@mcneil.com(Sean McNeil) said: > > > > > > > > sean> ping6 does NOT work for > > > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > > > sean> 2002:18c7:2d36:: > > > > > > > > > > It seems an IPv6 operation for dc0 is disabled entirely. Don't you > > > > > see an error message from your kernel like following? > > > > > dc0: possible hardware address duplication detected, disable IPv6 > > > > No, nothing like that in any logs. I can't see how there could > > > > suddenly be a duplication of hardware addresses. I agree, though, > > > > that IPv6 is disabled for dc0. Some change in the kernel has caused > > > > this. > > > > > > I tried the same configuration (with the different interface card) > > > using the latest RELENG-6 in my environment, but I couldn't reproduce > > > your problem. > > In order to really duplicate his configuration, you would need to use > the same network card. But of course you can't do that, because he > never mentioned just what card he has. > > The dc(4) driver supports a whole bunch of different chips. It really > really really matters that you tell us exactly which one you have. How could this possibly matter? There were no changes to the dc0 driver from Nov 1st to present. There were numerous ones to the IPv6 layer, though, that were MFCd recently. I can ping6 www.kame.net which goes through this nic, so IPv6 works through the stf pathway. Also, internal pings are completely dropped only on the nic tied to stf. I think it is more likely an amd64 vs i386 issue. Perhaps a long instead of an int somewhere. I would start with testing it on an amd64 machine first before looking for differences in the nics. > It would also really really help if you could run a packet dump on > dc0 while trying to ping6 it from another host. You should do > tcpdump -n -e -p -i dc0 so as not to force it into promisc mode. I did that and I get for each packet sent with the new kernel: 10:42:34.093463 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56: 0x0000: 0000 0203 6dff fe1a b19b 2002 18c7 2d36 ....m.........-6 0x0010: 0000 0203 6dff fe1a b19b 8000 1e51 0567 ....m........Q.g 0x0020: 0000 436f a01a 0001 6d01 ..Co....m. 10:42:35.093983 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56: 0x0000: 0000 0203 6dff fe1a b19b 2002 18c7 2d36 ....m.........-6 0x0010: 0000 0203 6dff fe1a b19b 8000 1c56 0567 ....m........V.g 0x0020: 0001 436f a01b 0001 6efa ..Co....n. 10:42:36.093883 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56: 0x0000: 0000 0203 6dff fe1a b19b 2002 18c7 2d36 ....m.........-6 0x0010: 0000 0203 6dff fe1a b19b 8000 1cb6 0567 ....m..........g 0x0020: 0002 436f a01c 0001 6e98 ..Co....n. 10:42:37.093795 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56: 0x0000: 0000 0203 6dff fe1a b19b 2002 18c7 2d36 ....m.........-6 0x0010: 0000 0203 6dff fe1a b19b 8000 1d0d 0567 ....m..........g 0x0020: 0003 436f a01d 0001 6e3f ..Co....n? The packets are going in, but nothing is coming out. The dump looks very peculiar for both the sk0 and the dc0 nic. None of the ethertypes are known. In contrast, the Nov 1 kernel that works shows me things like: 11:11:12.363832 00:03:6d:1a:b1:9b > 33:33:00:00:00:09, ethertype IPv6 (0x86dd), length 86: fe80::203:6dff:fe1a:b19b.521 > ff02::9.521: ripng-resp 1: 2002:18c7:2d36:1::/64 (1) Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 19:41:17 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4802116A41F; Mon, 7 Nov 2005 19:41:17 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BB343D48; Mon, 7 Nov 2005 19:41:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jA7JfEQL039565; Mon, 7 Nov 2005 14:41:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id jA7JfFBV051241; Mon, 7 Nov 2005 14:41:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5C3EB7302F; Mon, 7 Nov 2005 14:41:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051107194115.5C3EB7302F@freebsd-current.sentex.ca> Date: Mon, 7 Nov 2005 14:41:15 -0500 (EST) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 19:41:17 -0000 TB --- 2005-11-07 18:32:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-07 18:32:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-11-07 18:32:49 - cleaning the object tree TB --- 2005-11-07 18:33:19 - checking out the source tree TB --- 2005-11-07 18:33:19 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-11-07 18:33:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-07 18:40:17 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-07 18:40:17 - cd /src TB --- 2005-11-07 18:40: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 [...] cc -O2 -pipe -c /src/usr.sbin/ckdist/../../usr.bin/cksum/crc.c cc -O2 -pipe -o ckdist ckdist.o crc.o -lmd gzip -cn /src/usr.sbin/ckdist/ckdist.1 > ckdist.1.gz ===> usr.sbin/config (all) cc -O2 -pipe -I. -I/src/usr.sbin/config -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c config.c cc -O2 -pipe -I. -I/src/usr.sbin/config -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/usr.sbin/config/main.c In file included from /src/usr.sbin/config/main.c:57: /src/usr.sbin/config/configvers.h:10:12: "/*" within comment *** Error code 1 Stop in /src/usr.sbin/config. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-07 19:41:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-07 19:41:15 - ERROR: failed to build world TB --- 2005-11-07 19:41:15 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 20:46:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8FC16A41F for ; Mon, 7 Nov 2005 20:46:45 +0000 (GMT) (envelope-from tms3@fsklaw.com) Received: from thor-new.fsklaw.com (adsl-64-174-116-34.dsl.lsan03.pacbell.net [64.174.116.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 225F943D45 for ; Mon, 7 Nov 2005 20:46:44 +0000 (GMT) (envelope-from tms3@fsklaw.com) Received: from FUMS [192.168.64.164] by thor-new.fsklaw.com with SMTP (EHLO [192.168.64.164]) (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.8.1)); Mon, 7 Nov 2005 12:48:37 -0800 Message-ID: <436FBD99.20009@fsklaw.com> Date: Mon, 07 Nov 2005 12:48:25 -0800 From: "Thomas M. Skeren III" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 07 Nov 2005 20:53:48 +0000 Cc: Subject: FBSD 6.0 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 20:46:45 -0000 I cannot get an ISO to boot into the installer. I have tried 3 different AMD machines, an older Athlon 2000 with VIA chipset, a new Athlon 64x2 with NForce4 chipset, and an AMD64 Compaq laptop. All machines reboot after selecting either option 1 or 2. Both desktop machines have no problem with 5.4. What gives? TMS III P.S. I re-downloaded the ISO image, just to see if I had a bad ISO. Same thing. From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 20:54:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2C83D16A420; Mon, 7 Nov 2005 20:54:24 +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.4/8.13.1) with ESMTP id jA7KsNiL085952; Mon, 7 Nov 2005 15:54:23 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.4/8.13.1/Submit) id jA7KsMDL085951; Mon, 7 Nov 2005 15:54:22 -0500 (EST) (envelope-from green) Date: Mon, 7 Nov 2005 15:54:22 -0500 From: Brian Fundakowski Feldman To: Andre Oppermann Message-ID: <20051107205422.GD37350@green.homeunix.org> References: <20051104092724.GA33945@xor.obsecurity.org> <436B885B.6010609@freebsd.org> <20051104163526.GC82727@flame.pc> <200511041833.30955.thierry@herbelot.com> <436BA8B5.9070104@freebsd.org> <20051105003420.GM91530@cell.sick.ru> <20051105034105.GA906@flame.pc> <20051105080116.GR91530@cell.sick.ru> <20051105084924.GT91530@cell.sick.ru> <436D0C52.7A02137F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436D0C52.7A02137F@freebsd.org> User-Agent: Mutt/1.5.11 Cc: thierry@herbelot.com, sam@freebsd.org, Gleb Smirnoff , Giorgos Keramidas , freebsd-current@freebsd.org Subject: Re: panic: mb_dtor_pack: ref_cnt != 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 20:54:24 -0000 On Sat, Nov 05, 2005 at 08:47:30PM +0100, Andre Oppermann wrote: > Gleb Smirnoff wrote: > > > > On Sat, Nov 05, 2005 at 11:01:16AM +0300, Gleb Smirnoff wrote: > > T> On Sat, Nov 05, 2005 at 05:41:05AM +0200, Giorgos Keramidas wrote: > > T> G> On 2005-11-05 03:34, Gleb Smirnoff wrote: > > T> G> > Andre, Thierry, Sam, > > T> G> > > > T> G> > this patch should fix the problems > > T> G> > > T> G> But it panics in mb_dtor_pack() because ext_type != EXT_CLUSTER > > T> G> when my ath0 interface tries to associate with an AP. > > T> G> > > T> G> I had to change this too, to make things work: > > T> > > T> Updated patch. > > > > One more update. Since I have removed this block: > > > > if (*(m->m_ext.ref_cnt) == 0) > > *(m->m_ext.ref_cnt) = 1; > > > > I have also altered KASSERT in mb_dtor_pack(). I don't like > > inventing an incorrect invariant check and then adding helpers > > to avoid it being triggered. > > This block is still required for the packet zone as the refcount > is not re-initialized for mbuf+cluster out of the packet zone. > You may up with wrong refcounts if you remove this check. It > is not directly related to the KASSERT in mb_dtor_pack() but to > the way atomic_fetchadd_int() works in concurrency situations. > > I have committed a fix to the same effect as your proposed patch. > When UMA is fixed this may be reverted again. Could you submit a UMA bug report? There are a reasonable number of hackers around that can fix UMA/VM bugs. I wouldn't mind at trying my hand at one again these days. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 21:17:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0428A16A421; Mon, 7 Nov 2005 21:17:06 +0000 (GMT) (envelope-from martin@gneto.com) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DEB943D53; Mon, 7 Nov 2005 21:16:59 +0000 (GMT) (envelope-from martin@gneto.com) Received: from ua-83-227-181-30.cust.bredbandsbolaget.se ([83.227.181.30] [83.227.181.30]) by mxfep02.bredband.com with ESMTP id <20051107211657.YMNY16437.mxfep02.bredband.com@ua-83-227-181-30.cust.bredbandsbolaget.se>; Mon, 7 Nov 2005 22:16:57 +0100 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by ua-83-227-181-30.cust.bredbandsbolaget.se (Postfix) with ESMTP id 8141A678DC; Mon, 7 Nov 2005 22:16:57 +0100 (CET) Message-ID: <436FC449.4030600@gneto.com> Date: Mon, 07 Nov 2005 22:16:57 +0100 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051107) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, =?ISO-8859-1?Q?S=F8ren_Schmidt?= Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: FreeBSD 6.0 panic with intel RAID 10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 21:17:06 -0000 I'm testing one of the new ICH7R boards with intel biosRAID (Supermicro PDSMi). FreeBSD 6.0 panics during boot if I create a intel RAID 10 array. I changed to one RAID0 and one RAID1 and the system is installing as it should right now. What info should I provide to make RAID10 work? Sören do you have enough equipment to write complete support for the ICH7R? (AHCI, SATA-II, NCQ, RAID etc) Regards, Martin From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 21:36:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CE0116A421 for ; Mon, 7 Nov 2005 21:36:03 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D9543D58 for ; Mon, 7 Nov 2005 21:35:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1540412 for multiple; Mon, 07 Nov 2005 16:37:52 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7LZexM019048; Mon, 7 Nov 2005 16:35:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 7 Nov 2005 12:56:03 -0500 User-Agent: KMail/1.8.2 References: <436E66FB.60700@desk.pl> In-Reply-To: <436E66FB.60700@desk.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071256.04488.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Marcin Koziej Subject: Re: NVidia driver for amd64 / Page Attribute Table status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 21:36:03 -0000 On Sunday 06 November 2005 03:26 pm, Marcin Koziej wrote: > Hi, > > I have searched for some information about nVidia FreeBSD-amd64 driver > and reasons why it is not availible, but the whole situation seems to be > very mysterious. > > There are comments on nVidia forums from september by mr. Zander from > nVidia: > "There are technical problems with the FreeBSD/amd64 kernel that gate > NVIDIA graphics driver support for this platform. NVIDIA has brought > these problems up with FreeBSD developers and has been working with one > of them to make reliable support for FreeBSD/amd64 technically possible, > but unfortunately we can't provide a schedule for when this will be > complete." > (http://www.nvnews.net/vbulletin/showthread.php?t=41545&page=2) > > Both the developer and the 'technical problems with FreeBSD' are kept > secret... > There are some clues in freebsd-current archive: > "There are a few missing VM features that any high-performance graphics > card driver would require for decent performance with PCI Express. John > is working on adding those features - have patience." > > and > > "Actually I think that the feature we are talking about (PAT) is > relevant to both amd64 and i386. Proper support for PAT is required for > decent PCI Express performance, as I understand it." > > (http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052740.html > http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052746.html) > > Is Page Attribute Table feature blocking nVidia drivers? > What is the status of this feature then? > Can someone informed enough shed some light on the story? > > Thanks for Your time, > m. It's not finished, no. The WIP is being done in the p4_pat branch (though it has some crud in it now that probably isn't needed). For more info about PAT and memory caching modes on x86 including MTRR's, etc. you can go download the vol 2 IA-32 arch PDF from developer.intel.com. It's not a conspiracy, there are no black helicopters. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 21:36:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B55916A41F; Mon, 7 Nov 2005 21:36:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCC743D53; Mon, 7 Nov 2005 21:35:46 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1540409 for multiple; Mon, 07 Nov 2005 16:37:49 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7LZexL019048; Mon, 7 Nov 2005 16:35:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 7 Nov 2005 12:52:56 -0500 User-Agent: KMail/1.8.2 References: <17260.17957.473953.634330@roam.psg.com> <17260.41826.683167.533287@roam.psg.com> <20051105181517.K22029@fledge.watson.org> In-Reply-To: <20051105181517.K22029@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071252.58060.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Randy Bush , Robert Watson Subject: Re: ipi_nmi_handler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 21:36:04 -0000 On Saturday 05 November 2005 01:16 pm, Robert Watson wrote: > On Sat, 5 Nov 2005, Randy Bush wrote: > >> It seems that if you put STOP_NMI in your kernel config, you need SMP as > >> well. > > > > > > > > is STOP_NMI so wonderful that i should turn on SMP and the apic device? > > STOP_NMI makes inter-processor interrupts for the debugger (and a few > other things) use non-maskable interrupts instead of maskable ones. So it > doesn't actually do anything if you don't have an SMP system, as there > will be no inter-processor interrupts on a single-processor system. > > The STOP_NMI option may have been turned on by default without realizing > that it wasn't quite implemented right -- it should only affect SMP > systems, not be limited to compiling on them. It was only turned on in GENERIC in HEAD which has SMP. It would be akin to trying to remove 'device apic' but keep 'options SMP' and expect things to still build, though on perhaps a lesser scale. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 22:41:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D187116A425; Mon, 7 Nov 2005 22:41:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7CA643D67; Mon, 7 Nov 2005 22:41:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1544388 for multiple; Mon, 07 Nov 2005 17:43:32 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7MfNXd019442; Mon, 7 Nov 2005 17:41:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 7 Nov 2005 16:37:53 -0500 User-Agent: KMail/1.8.2 References: <436FBD99.20009@fsklaw.com> In-Reply-To: <436FBD99.20009@fsklaw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071637.55082.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: "Thomas M. Skeren III" , current@freebsd.org Subject: Re: FBSD 6.0 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 22:41:36 -0000 On Monday 07 November 2005 03:48 pm, Thomas M. Skeren III wrote: > I cannot get an ISO to boot into the installer. I have tried 3 > different AMD machines, an older Athlon 2000 with VIA chipset, a new > Athlon 64x2 with NForce4 chipset, and an AMD64 Compaq laptop. All > machines reboot after selecting either option 1 or 2. Both desktop > machines have no problem with 5.4. > > What gives? We need some more details. Does it print anything on the screen before it reboots? It would be especially helpful if you could hook up a serial console to capture any messages printed out before the reboot. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 22:41:35 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D187116A425; Mon, 7 Nov 2005 22:41:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7CA643D67; Mon, 7 Nov 2005 22:41:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1544388 for multiple; Mon, 07 Nov 2005 17:43:32 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7MfNXd019442; Mon, 7 Nov 2005 17:41:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 7 Nov 2005 16:37:53 -0500 User-Agent: KMail/1.8.2 References: <436FBD99.20009@fsklaw.com> In-Reply-To: <436FBD99.20009@fsklaw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071637.55082.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: "Thomas M. Skeren III" , current@freebsd.org Subject: Re: FBSD 6.0 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 22:41:36 -0000 On Monday 07 November 2005 03:48 pm, Thomas M. Skeren III wrote: > I cannot get an ISO to boot into the installer. I have tried 3 > different AMD machines, an older Athlon 2000 with VIA chipset, a new > Athlon 64x2 with NForce4 chipset, and an AMD64 Compaq laptop. All > machines reboot after selecting either option 1 or 2. Both desktop > machines have no problem with 5.4. > > What gives? We need some more details. Does it print anything on the screen before it reboots? It would be especially helpful if you could hook up a serial console to capture any messages printed out before the reboot. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 22:41:38 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E5EC16A422 for ; Mon, 7 Nov 2005 22:41:38 +0000 (GMT) (envelope-from full-disclosure@csilva.org) Received: from jupiter.nswebhost.com (jupiter.nswebhost.com [72.9.236.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D8343D64 for ; Mon, 7 Nov 2005 22:41:31 +0000 (GMT) (envelope-from full-disclosure@csilva.org) Received: from 55-246.dial.nortenet.pt ([212.13.55.246]:34828 helo=[192.168.1.10]) by jupiter.nswebhost.com with esmtpa (Exim 4.52) id 1EZFfz-00028b-Bg for freebsd-current@FreeBSD.org; Mon, 07 Nov 2005 17:41:19 -0500 Message-ID: <436FD822.5000002@csilva.org> Date: Mon, 07 Nov 2005 22:41:38 +0000 From: Carlos Silva aka |Danger_Man| User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jupiter.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - csilva.org X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Security updates without rebooting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Nov 2005 22:41:38 -0000 Hello all, Can someone explain how to apply security patches on the system without rebooting the machine? I guess that I cant patch the kernel without compiling and rebooting the machine, so the only way is with iptables and keeping the daemons "fresh"? Regards, Carlos Silva, http://osiris.csilva.org/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 22:59:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E54616A41F; Mon, 7 Nov 2005 22:59:15 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0AAA43D72; Mon, 7 Nov 2005 22:58:55 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from maverick.trit.org (maverick.trit.org [IPv6:2001:4830:2381:2fe2::2]) by charade.trit.org (Postfix) with ESMTP id 7E2D51AF460; Mon, 7 Nov 2005 22:58:55 +0000 (UTC) Received: from maverick.trit.org (localhost [127.0.0.1]) by maverick.trit.org (8.13.4/8.13.4) with ESMTP id jA7MwsU0001120; Mon, 7 Nov 2005 22:58:54 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by maverick.trit.org (8.13.4/8.13.4/Submit) id jA7MwsvO001119; Mon, 7 Nov 2005 22:58:54 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: maverick.trit.org: dima set sender to dd@freebsd.org using -f Date: Mon, 7 Nov 2005 22:58:54 +0000 From: Dima Dorfman To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051107225853.GA1069@trit.org> References: <20041116145445.EC71167E2B@gunfright.epcdirect.co.uk> <419B177D.2090206@DeepCore.dk> <20051107092007.GA1240@trit.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: X-PGP-Key: 69FAE582 (http://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: Mutt/1.5.9i Cc: current@freebsd.org Subject: Re: Marvell SATA Support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 22:59:15 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable S=F8ren Schmidt wrote: > On 07/11/2005, at 10:20, Dima Dorfman wrote: > > noneX@pciX:Y:Z: class=3DXXX card=3D0x518015d9 chip=3D0x504111ab rev=3D0= x00 hdr=3D0x00 > > vendor =3D 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device =3D '88SX504 4-port SATA I PCI-X Controller' > > class =3D mass storage > > subclass =3D RAID > > > >In its current state, I can't see any disks attached to this > >controller. Is there an easy way to make it work without RAID? I'd > >hate to put another controller into this box. >=20 > The marvell chips doesn't look like a normal ATA controller *at all*, =20 > they are very different animals that actually could be dealt with in =20 > a seperate driver if need be. Okay, thanks. Sounds like I'll have to get another controller for now. Since the BIOS and the loader can see the drives, would it be possible to make the ata driver use the BIOS interface to attach the disks? Any way to see them, even if it's slow, is better than not seeing them at all. It's an embedded controller, so being able to use it in at least some capacity would be nice. Thanks, Dima. --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD4DBQFDb9wtBzAFW2n65YIRAmN7AJdCmbmdiwd4D9nB4ziqPgas5ac3AJ9uVhj0 pQVyrsfeLC7rZ+eOcSPnyg== =/TKn -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 7 23:51:19 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307D516A41F; Mon, 7 Nov 2005 23:51:19 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DC2D43D95; Mon, 7 Nov 2005 23:50:58 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jA7NotSa043038; Mon, 7 Nov 2005 15:50:55 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jA7NosSi043037; Mon, 7 Nov 2005 15:50:54 -0800 (PST) (envelope-from jmg) Date: Mon, 7 Nov 2005 15:50:54 -0800 From: John-Mark Gurney To: Robert Watson Message-ID: <20051107235054.GG775@funkthat.com> Mail-Followup-To: Robert Watson , Jeremie Le Hen , Andrew Lankford , current@freebsd.org References: <433E9C4F.8040404@charter.net> <20051002124424.D71864@fledge.watson.org> <20051003115659.GJ43195@obiwan.tataz.chchile.org> <20051107142621.Q9690@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107142621.Q9690@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 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: Andrew Lankford , Jeremie Le Hen , current@FreeBSD.org Subject: Re: RELENG_6 Kernel doesn't build due to DEVFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Nov 2005 23:51:19 -0000 Robert Watson wrote this message on Mon, Nov 07, 2005 at 14:31 +0000: > older compiler incorrectly rejecting it as invalid. Ideally, commits to > update the compiler are made, and then after some longish delay (a few > weeks), the source code is updated to make use of new compiler features. > In this case, the changes came in close proximity, resulting in a few more > stubbed toes. Ideally, people would use the buildworld/buildkernel to build their kernel, and if they really want the developer experience of building a kernel, they can use buildworld/buildenv which will deal with the problem of outdated compilers automagicly for you... -- 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 Tue Nov 8 00:55:09 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C94AE16A420 for ; Tue, 8 Nov 2005 00:55:09 +0000 (GMT) (envelope-from yoshint@flab.fujitsu.co.jp) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE25C43D49 for ; Tue, 8 Nov 2005 00:55:07 +0000 (GMT) (envelope-from yoshint@flab.fujitsu.co.jp) Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) id jA80t6LZ022729 for ; Tue, 8 Nov 2005 09:55:06 +0900 (envelope-from yoshint@flab.fujitsu.co.jp) Received: from s1.gw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id jA80t508001729 for ; Tue, 8 Nov 2005 09:55:05 +0900 (envelope-from yoshint@flab.fujitsu.co.jp) Received: from s1.gw.fujitsu.co.jp (s1 [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id DEAB4178156 for ; Tue, 8 Nov 2005 09:55:04 +0900 (JST) Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6F73517814C for ; Tue, 8 Nov 2005 09:55:04 +0900 (JST) Received: from dm.kawasaki.flab.fujitsu.co.jp by dm.kawasaki.flab.fujitsu.co.jp (8.9.3p2/3.7W-051028-Fujitsu Labs. Kawasaki Domain Mail Master (NAVGW)) id JAA18946; Tue, 8 Nov 2005 09:55:04 +0900 (JST) Received: from palomino.cad.flab.fujitsu.co.jp ([10.25.155.139]) by dm.kawasaki.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2005110809550318058 for ; Tue, 08 Nov 2005 09:55:03 +0900 Received: from palomino.cad.flab.fujitsu.co.jp (localhost [IPv6:::1]) by palomino.cad.flab.fujitsu.co.jp (8.13.3/8.13.1) with ESMTP id jA80t148018267 for ; Tue, 8 Nov 2005 09:55:03 +0900 (JST) (envelope-from yoshint@flab.fujitsu.co.jp) From: TOMITA Yoshinori To: freebsd-current@FreeBSD.org MIME-Version: 1.0 (generated by WEMIKO 1.14.1 - =?ISO-2022-JP?B?Ig==?= =?ISO-2022-JP?B?GyRCNl9KXExTQ24bKEIi?=) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Nov 2005 09:55:01 +0900 Message-ID: User-Agent: T-gnus/6.17.4 (based on No Gnus v0.4) WEMIKO/1.14.1 (=?ISO-2022-JP?B?GyRCNl9KXExTQ24bKEI=?=) SLIM/1.14.7 (=?ISO-2022-JP?B?GyRCPHIwZjpMTD4bKEI=?=) APEL/10.3 XEmacs/21.4.17 (i386-unknown-freebsd5.4) MULE Mule-UCS/0.84 (=?ISO-2022-JP?B?S09VR0VU?= =?ISO-2022-JP?B?U1VEQUk6GyRCOH43bkJmGyhC?=) Cc: Subject: FreeBSD 6.0 TCP NFS client stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 00:55:09 -0000 I saw a NFS client of FreeBSD 6.0-RC1 gets NFS stuck using TCP NFS and amd -w LARGE_NUMBER, where -w specifies dismount interval such as 3600. 6.0-STABLE cvsuped 2005-11-7 has same problem. It has always been OK on FreeBSD 4.X to 5.4-STABLE. FreeBSD 6.0 NFS client seems keep trying NFS access forever after NFS TCP connection is (half?) closed. I am not sure amd and -w argument are the key of this problem, but they raise probability from my experience. NFS Server: Solaris 2.6 NFS Client: FreeBSD 6.0-RC1 (cvsuped 2005-11-02) Starting amd at FreeBSD: /usr/sbin/amd -p -w 3600 -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map /etc/amd.map: # changed proto=udp to proto=tcp ------ /defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key} * opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev ------ tcpdump log: -------------------------------------------------- [several minutes passed after NFS auto-mounted] 11:09:38.852928 IP CLIENT.3254779904 > SERVER.nfs: 40 null 11:09:38.853261 IP SERVER.nfs > CLIENT.3254779904: reply ok 24 null 11:10:08.851290 IP CLIENT.3523215360 > SERVER.nfs: 40 null 11:10:08.851529 IP SERVER.nfs > CLIENT.3523215360: reply ok 24 null [FIN from NFS server, FreeBSD NFS client sends ACK] 11:10:08.854469 IP SERVER.nfsd > CLIENT.820: F 341:341(0) ack 200 win 10136 11:10:08.854555 IP CLIENT.820 > SERVER.nfsd: . ack 342 win 65535 11:10:08.864321 IP SERVER.nfsd > CLIENT.679: F 341:341(0) ack 200 win 10136 11:10:08.864383 IP CLIENT.679 > SERVER.nfsd: . ack 342 win 65535 11:10:08.895133 IP SERVER.nfsd > CLIENT.735: F 40141:40141(0) ack 1900 win 10136 11:10:08.895203 IP CLIENT.735 > SERVER.nfsd: . ack 40142 win 65535 [still NFS NULL continues from FreeBSD NFS client] 11:10:38.849614 IP CLIENT.3791650816 > SERVER.nfs: 40 null 11:10:38.849906 IP SERVER.nfs > CLIENT.3791650816: reply ok 24 null 11:11:08.847947 IP CLIENT.4060086272 > SERVER.nfs: 40 null 11:11:08.848289 IP SERVER.nfs > CLIENT.4060086272: reply ok 24 null 11:11:38.846275 IP CLIENT.33619968 > SERVER.nfs: 40 null 11:11:38.846555 IP SERVER.nfs > CLIENT.33619968: reply ok 24 null [do some NFS access, such as /bin/ls /host/SERVER/SOMEWHERE on FreeBSD] 11:12:08.413414 IP CLIENT.302055424 > SERVER.nfs: 40 null 11:12:08.413797 IP SERVER.nfs > CLIENT.302055424: reply ok 24 null 11:12:08.414096 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:08.507632 IP SERVER.nfsd > CLIENT.735: . ack 2032 win 10136 11:12:10.083443 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:10.177666 IP SERVER.nfsd > CLIENT.735: . ack 2164 win 10136 11:12:11.743299 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:11.837696 IP SERVER.nfsd > CLIENT.735: . ack 2296 win 10136 11:12:15.063018 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:15.157790 IP SERVER.nfsd > CLIENT.735: . ack 2428 win 10136 11:12:21.702417 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:21.798028 IP SERVER.nfsd > CLIENT.735: . ack 2560 win 10136 11:12:34.981251 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] 11:12:35.078429 IP SERVER.nfsd > CLIENT.735: . ack 2692 win 10136 11:12:38.411967 IP CLIENT.570490880 > SERVER.nfs: 40 null 11:12:38.412267 IP SERVER.nfs > CLIENT.570490880: reply ok 24 null 11:13:01.538891 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] [----> message repeats on FreeBSD NFS client] nfs server SERVER:/export/home: not responding -------------------------------------------------- [netstat @ Solaris NFS server, when NFS is OK] SERVER.nfsd CLIENT.820 131070 0 10136 0 ESTABLISHED SERVER.nfsd CLIENT.735 131070 0 10136 0 ESTABLISHED SERVER.nfsd CLIENT.679 131070 0 10136 0 ESTABLISHED [after NFS stuck] SERVER.nfsd CLIENT.820 131070 0 10136 0 FIN_WAIT_2 SERVER.nfsd CLIENT.735 131070 0 10136 0 FIN_WAIT_2 SERVER.nfsd CLIENT.679 131070 0 10136 0 FIN_WAIT_2 [netstat @ FreeBSD NFS client, after NFS stuck] tcp4 0 0 CLIENT.679 SERVER.nfsd CLOSE_WAIT tcp4 0 0 CLIENT.735 SERVER.nfsd CLOSE_WAIT tcp4 0 0 CLIENT.820 SERVER.nfsd CLOSE_WAIT -- --- TOMITA Yoshinori (Fujitsu Laboratories Ltd., Kawasaki, Japan) From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 01:38:02 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F5AF16A420; Tue, 8 Nov 2005 01:38:02 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (mail-svr1.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAFD043D55; Tue, 8 Nov 2005 01:38:01 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id DA366346E0; Mon, 7 Nov 2005 18:38:00 -0700 (MST) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15215-09; Mon, 7 Nov 2005 18:38:00 -0700 (MST) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 816B034692; Mon, 7 Nov 2005 18:38:00 -0700 (MST) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 754343F71; Mon, 7 Nov 2005 18:38:00 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 726BC3F6C; Mon, 7 Nov 2005 18:38:00 -0700 (MST) Date: Mon, 7 Nov 2005 18:38:00 -0700 (MST) From: Vaibhave Agarwal To: John Baldwin In-Reply-To: <200511071105.58729.jhb@freebsd.org> Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> <436E874E.4010305@root.org> <200511071105.58729.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd-net@freebsd.org, freebsd-acpi@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 01:38:02 -0000 On Mon, 7 Nov 2005, John Baldwin wrote: > And even then it can't be used for any device interrupts since there aren't > any I/O APICs. On a UP machine without I/O APICs, it's actually probably > more optimal to just use irq0 and irq8 for clocks rather than the lapic timer > anyway. The only real possible gain is the ability to use the profiling > interrupt from the local APIC. I got access to the BIOS of the Pentium 3 machine I am using, but it has no option to enable/disable the local APIC. Joseph Koshy is right, Linux enables the local APIC timer while booting up. I got the following in the bootup log of Linux 2.4 kernel on the same machine. ------------------------- Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Using local APIC timer interrupts. calibrating APIC timer ... ------------------------- Though there is no I/O apic in the UP machines, but I only wanted to use local APIC timer in the lapic_timer_oneshot() mode to schedule few timers accurately. thanks vaibhave From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 01:53:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A306D16A41F; Tue, 8 Nov 2005 01:53:24 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4483B43D60; Tue, 8 Nov 2005 01:53:15 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id ECC2D62B9; Tue, 8 Nov 2005 10:54:30 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56897-05; Tue, 8 Nov 2005 10:54:25 +0900 (JST) Received: from flora220.uki-uki.net (unknown [209.52.153.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id C7EDA62AA; Tue, 8 Nov 2005 10:54:24 +0900 (JST) Date: Mon, 07 Nov 2005 17:51:52 -0800 Message-ID: From: SUZUKI Shinsuke To: sean@mcneil.com X-cite: xcite 1.33 In-Reply-To: <1131359967.1874.6.camel@server.mcneil.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 01:53:24 -0000 Hello Sean, >>>>> On Mon, 07 Nov 2005 02:39:27 -0800 >>>>> sean@mcneil.com(Sean McNeil) said: > > > > sean> ping6 does NOT work for > > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > > sean> 2002:18c7:2d36:: > > > > So could you please show me the result of the following commands? (snip) Hmm. Judging from the result, layer 3 is properly working. So I cannot locate the problem yet... - NDP cache is properly created for dc0's local address - loopback address exists - IPv6 is not disabled on dc0 (assuming usr.sbin/ndp is also updated to the latest one, which displays "disabled" if the IPv6 operation is administratively disabled) To narrow the problem further, could you please try with the RELENG_6 kernel at Nov 5 00:00 2005 UTC? During Nov.1-11, there are two kinds of kernel MFCs regarding IPv6 (scope clean-up@Nov 4 20:26, disabling IPv6 per interface@Nov 5 10:30). And I'd like to know which one brings about your problem. Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 02:09:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A579216A41F for ; Tue, 8 Nov 2005 02:09:00 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BCC343D45 for ; Tue, 8 Nov 2005 02:09:00 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so538343wxc for ; Mon, 07 Nov 2005 18:08:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aDUOfH2oKtyMFa39WUQlM6wdEDXFSa/CPVnsAJSN0YZRV1776bD6AGiN1TOUoF9DZUOY17l+dU9cnqKDEEgBHHVd+3MzofOjXaBkmBZHuauRry6EIUme1b4qoTP8licnl10/tgYh+O5F1OCIHgSrdrFKQim78SJ7sCl2Ii2+0wk= Received: by 10.70.31.10 with SMTP id e10mr3017229wxe; Mon, 07 Nov 2005 18:08:59 -0800 (PST) Received: by 10.70.105.13 with HTTP; Mon, 7 Nov 2005 18:08:58 -0800 (PST) Message-ID: <84dead720511071808m1b0c59e5i49992b478d4724af@mail.gmail.com> Date: Tue, 8 Nov 2005 07:38:59 +0530 From: Joseph Koshy To: Carlos Silva aka |Danger_Man| In-Reply-To: <436FD822.5000002@csilva.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <436FD822.5000002@csilva.org> Cc: freebsd-current@freebsd.org Subject: Re: Security updates without rebooting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 02:09:00 -0000 > Can someone explain how to apply security patches on the > system without rebooting the machine? Application programs can be stopped and restarted at will; you can do this in a controlled way using the application's startup script in /etc/rc.d/ if that exists. Kernel patches generally require a reboot though, though some simple changes to some kernel modules could get by with a 'kldunload' followed by a 'kldload'. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 02:57:58 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FD5C16A41F; Tue, 8 Nov 2005 02:57:58 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C6E43D45; Tue, 8 Nov 2005 02:57:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7B1F43FF2A; Tue, 8 Nov 2005 03:57:56 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 956194083; Tue, 8 Nov 2005 03:57:33 +0100 (CET) Date: Tue, 8 Nov 2005 03:57:33 +0100 From: Jeremie Le Hen To: Robert Watson Message-ID: <20051108025733.GA1165@obiwan.tataz.chchile.org> References: <433E9C4F.8040404@charter.net> <20051002124424.D71864@fledge.watson.org> <20051003115659.GJ43195@obiwan.tataz.chchile.org> <20051107142621.Q9690@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051107142621.Q9690@fledge.watson.org> User-Agent: Mutt/1.5.11 Cc: Andrew Lankford , Jeremie Le Hen , current@freebsd.org Subject: Re: RELENG_6 Kernel doesn't build due to DEVFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 02:57:58 -0000 Robert, > Sorry about the delay in responding to this, just found your e-mail while > starting to catch up on some older ones. The tweak below fixes a bug in > which valid syntax was not accepted by the computer. This was followed by > several commits that introduced that valid syntax into the source tree, > meaning that the tree would not build with an older compiler due to the > older compiler incorrectly rejecting it as invalid. Ideally, commits to > update the compiler are made, and then after some longish delay (a few > weeks), the source code is updated to make use of new compiler features. > In this case, the changes came in close proximity, resulting in a few more > stubbed toes. No problem for the delay, thank you very much, you are very obliging. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 00:05:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07B1316A41F; Tue, 8 Nov 2005 00:05:38 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD56D43D45; Tue, 8 Nov 2005 00:05:37 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 6EEA82FD8; Mon, 7 Nov 2005 18:05:37 -0600 (CST) Date: Mon, 7 Nov 2005 18:05:37 -0600 To: Sean McNeil Message-ID: <20051108000537.GC16191@soaustin.net> References: <20051107182338.2D9CE16A420@hub.freebsd.org> <1131391243.1343.6.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131391243.1343.6.camel@server.mcneil.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 08 Nov 2005 04:18:21 +0000 Cc: Bill Paul , ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 00:05:38 -0000 On Mon, Nov 07, 2005 at 11:20:43AM -0800, Sean McNeil wrote: > > The dc(4) driver supports a whole bunch of different chips. It really > > really really matters that you tell us exactly which one you have. > > How could this possibly matter? There were no changes to the dc0 driver > from Nov 1st to present. The essence of good bug reports is to report any fact that might _possibly_ be relevant. It helps to quickly eliminate possibilities. This isn't just true for FreeBSD; I have fought this battle for decades in this profession. Sometimes even as I'm composing a bug report I find myself walking through my list of unstated assumptions about what the problem "must" be. Half the time one of my assumptions is bogus. This is not a criticism of the OP, this is just how engineering works -- if we presuppose too much about the problem, rather than just reporting symptoms, we can wind up going around in circles. The PR database has many hundreds of such entries, unfortunately. mcl From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 01:05:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E3DD16A41F; Tue, 8 Nov 2005 01:05:57 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9DE143D46; Tue, 8 Nov 2005 01:05:56 +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 7B270F2425; Mon, 7 Nov 2005 17:05:56 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00808-01; Mon, 7 Nov 2005 17:05:55 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9E407F1C72; Mon, 7 Nov 2005 17:05:55 -0800 (PST) From: Sean McNeil To: Mark Linimon In-Reply-To: <20051108000537.GC16191@soaustin.net> References: <20051107182338.2D9CE16A420@hub.freebsd.org> <1131391243.1343.6.camel@server.mcneil.com> <20051108000537.GC16191@soaustin.net> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Mon, 07 Nov 2005 17:05:55 -0800 Message-Id: <1131411955.1350.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Tue, 08 Nov 2005 04:19:08 +0000 Cc: Bill Paul , ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 01:05:57 -0000 On Mon, 2005-11-07 at 18:05 -0600, Mark Linimon wrote: > On Mon, Nov 07, 2005 at 11:20:43AM -0800, Sean McNeil wrote: > > > The dc(4) driver supports a whole bunch of different chips. It really > > > really really matters that you tell us exactly which one you have. > > > > How could this possibly matter? There were no changes to the dc0 driver > > from Nov 1st to present. > > The essence of good bug reports is to report any fact that might _possibly_ > be relevant. It helps to quickly eliminate possibilities. > > This isn't just true for FreeBSD; I have fought this battle for decades > in this profession. Sometimes even as I'm composing a bug report I find > myself walking through my list of unstated assumptions about what the > problem "must" be. Half the time one of my assumptions is bogus. > > This is not a criticism of the OP, this is just how engineering works -- > if we presuppose too much about the problem, rather than just reporting > symptoms, we can wind up going around in circles. > > The PR database has many hundreds of such entries, unfortunately. Guess I sounded too defensive on that point. I was curious, though, as we are really tracking down a change that killed IPv6 in a particular way. I've been guilty of overlooking evidence myself in the past, but I honestly do not see the relevance in this case. In the name of full disclosure, here is my hardware: Gigabyte K8 Triton series with 3800+ 2x Athlon, 2GB DDR 400 RAM and builtin sk0 Marvell gigE for internal network. Old Linksys dc0 PCI card that I can look at to get additional info if required. dmesg info: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2080.20-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs real memory = 2147418112 (2047 MB) avail memory = 2062999552 (1967 MB) ACPI APIC Table: ... dc0: port 0xa400-0xa4ff mem 0xf5005000-0xf50053ff irq 17 at device 9.0 on pci2 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:03:6d:1a:b1:9b skc0: port 0xa800-0xa8ff mem 0xf5000000-0xf5003fff irq 19 at device 11.0 on pci2 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:14:85:85:27:b3 miibus1: on sk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ... Of additional interest is the fact that I can actually ping6 both interfaces from my Powerbook running Tiger 10.4.3. It is connected on the sk0 side. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 05:10:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 950D116A41F for ; Tue, 8 Nov 2005 05:10:13 +0000 (GMT) (envelope-from genjokoan@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F16743D4C for ; Tue, 8 Nov 2005 05:10:13 +0000 (GMT) (envelope-from genjokoan@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so611607wxc for ; Mon, 07 Nov 2005 21:10:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=eYSwuOHa+ydsLqaJKKDDxSYULy8fD8K5pYjxyjSVW+tpMeKQwmFEw013Pevlp3jSTMAr6cwebrwJMGPBlrq8qDyZXGpT3b9YJoOqQW0yTS/HuJUUcysmXiC9xyY0eNoO/qy7Gy1hb4xGmD+LwUNyaIchacoQaG6Dqi6ZJaubu4Q= Received: by 10.70.24.17 with SMTP id 17mr5890071wxx; Mon, 07 Nov 2005 20:45:58 -0800 (PST) Received: by 10.70.42.14 with HTTP; Mon, 7 Nov 2005 20:45:58 -0800 (PST) Message-ID: Date: Mon, 7 Nov 2005 23:45:58 -0500 From: Jan Isley To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 05:10:13 -0000 Trying to install amd64 6.0 release on some Dells, PE850 and PE2850.=20 BIOS all setup same as what works just fine with 5.4 (both i386 and amd64 cds). boot -h appears to work until it gets to the loader and the console output goes to video. No keyboards or monitors plugged in, just a serial console server. Have tried variations on serial redirect in the BIOS but nothing seems to work. Anyone else have success or no with serial console redirect on amd64 6.0 cd= ? regards, -Jan From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 04:34:42 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C31016A41F; Tue, 8 Nov 2005 04:34:42 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E073943D46; Tue, 8 Nov 2005 04:34:41 +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 7A8B5F2486; Mon, 7 Nov 2005 20:34:41 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00806-01; Mon, 7 Nov 2005 20:34:39 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 5C79EF23D9; Mon, 7 Nov 2005 20:34:39 -0800 (PST) From: Sean McNeil To: SUZUKI Shinsuke In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Mon, 07 Nov 2005 20:34:38 -0800 Message-Id: <1131424479.1341.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Tue, 08 Nov 2005 05:13:55 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 04:34:42 -0000 On Mon, 2005-11-07 at 17:51 -0800, SUZUKI Shinsuke wrote: > Hello Sean, > > >>>>> On Mon, 07 Nov 2005 02:39:27 -0800 > >>>>> sean@mcneil.com(Sean McNeil) said: > > > > > > sean> ping6 does NOT work for > > > > > sean> fe80::203:6dff:fe1a:b19b%dc0 > > > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b > > > > > sean> 2002:18c7:2d36:: > > > > > > So could you please show me the result of the following commands? > (snip) > > Hmm. > Judging from the result, layer 3 is properly working. > So I cannot locate the problem yet... > - NDP cache is properly created for dc0's local address > - loopback address exists > - IPv6 is not disabled on dc0 (assuming usr.sbin/ndp is also > updated to the latest one, which displays "disabled" if the > IPv6 operation is administratively disabled) > > To narrow the problem further, could you please try with the RELENG_6 > kernel at Nov 5 00:00 2005 UTC? During Nov.1-11, there are two kinds > of kernel MFCs regarding IPv6 (scope clean-up@Nov 4 20:26, disabling > IPv6 per interface@Nov 5 10:30). And I'd like to know which one > brings about your problem. Narrowed down to one day: date=2005.11.05.00.00.00 The problem exists. date=2005.11.04.00.00.00 The problem does not exist. So it has to be one of Edit src/sys/netinet/icmp6.h Add delta 1.16.2.2 2005.10.09.05.34.33 ume Edit src/sys/netinet/in.c Add delta 1.85.2.4 2005.10.15.16.58.21 rwatson Edit src/sys/netinet/ip_carp.c Add delta 1.27.2.2 2005.09.12.13.37.56 glebius Edit src/sys/netinet/ip_fw2.c Add delta 1.106.2.3 2005.09.17.13.43.36 bz Edit src/sys/netinet/raw_ip.c Add delta 1.150.2.2 2005.10.02.15.45.47 andre Edit src/sys/netinet/tcp_subr.c Add delta 1.228.2.4 2005.10.09.08.19.16 maxim Edit src/sys/netinet/tcp_usrreq.c Add delta 1.124.2.1 2005.10.09.03.17.41 delphij Edit src/sys/netinet/udp_usrreq.c Add delta 1.175.2.2 2005.10.02.15.45.47 andre Edit src/sys/netinet6/ah_core.c Add delta 1.25 2005.01.07.02.30.34 imp Edit src/sys/netinet6/esp_aesctr.c Add delta 1.2 2005.01.07.02.30.34 imp Edit src/sys/netinet6/icmp6.c Add delta 1.62.2.2 2005.11.04.20.41.08 ume Add delta 1.62.2.1 2005.11.04.20.26.15 ume Add delta 1.62 2005.05.15.02.28.29 gnn Edit src/sys/netinet6/in6.c Add delta 1.51.2.2 2005.11.01.22.48.56 suz Edit src/sys/netinet6/in6.h Add delta 1.36.2.3 2005.11.04.20.26.15 ume Add delta 1.36.2.2 2005.10.09.05.21.18 ume Edit src/sys/netinet6/in6_cksum.c Add delta 1.10 2005.01.07.02.30.34 imp Edit src/sys/netinet6/in6_ifattach.c Add delta 1.26.2.1 2005.09.13.18.02.39 thompsa Edit src/sys/netinet6/in6_pcb.c Add delta 1.62 2005.01.07.02.30.34 imp Edit src/sys/netinet6/in6_proto.c Add delta 1.32.2.2 2005.11.04.20.26.15 ume Add delta 1.32.2.1 2005.08.18.09.01.48 suz Edit src/sys/netinet6/in6_src.c Add delta 1.30.2.2 2005.11.04.20.26.15 ume Add delta 1.30.2.1 2005.08.20.12.20.48 ume Edit src/sys/netinet6/in6_var.h Add delta 1.21.2.2 2005.11.04.20.26.15 ume Add delta 1.21.2.1 2005.08.24.15.18.38 rwatson Edit src/sys/netinet6/ip6_forward.c Add delta 1.28.2.1 2005.08.18.09.01.48 suz Edit src/sys/netinet6/ip6_input.c Add delta 1.81.2.1 2005.10.09.05.21.18 ume Edit src/sys/netinet6/ip6_mroute.c Add delta 1.29.2.3 2005.11.04.20.26.15 ume Add delta 1.29.2.2 2005.10.27.14.04.03 suz Edit src/sys/netinet6/ip6_output.c Add delta 1.90.2.6 2005.11.04.20.26.15 ume Add delta 1.90.2.5 2005.11.04.19.59.55 ume Add delta 1.90.2.4 2005.10.09.06.51.11 ume Edit src/sys/netinet6/ip6_var.h Add delta 1.30.2.4 2005.11.04.20.26.15 ume Add delta 1.30.2.3 2005.11.04.19.59.55 ume Add delta 1.30.2.2 2005.10.09.06.51.11 ume Edit src/sys/netinet6/ipsec.c Add delta 1.42 2005.03.09.14.39.48 ume Edit src/sys/netinet6/mld6.c Add delta 1.19.2.2 2005.10.09.06.51.11 ume Edit src/sys/netinet6/nd6.c Add delta 1.48.2.5 2005.11.04.20.26.15 ume Add delta 1.48.2.4 2005.10.28.14.38.55 suz Edit src/sys/netinet6/nd6_nbr.c Add delta 1.29.2.3 2005.11.04.20.26.15 ume Add delta 1.29.2.2 2005.09.13.18.02.39 thompsa Edit src/sys/netinet6/nd6_rtr.c Add delta 1.26.2.1 2005.11.04.20.26.15 ume Add delta 1.26 2005.01.07.02.30.35 imp Edit src/sys/netinet6/raw_ip6.c Add delta 1.50.2.5 2005.11.04.19.59.55 ume Add delta 1.50.2.4 2005.11.04.19.57.31 ume Add delta 1.50.2.3 2005.10.20.11.49.25 suz Edit src/sys/netinet6/route6.c Add delta 1.11 2005.01.07.02.30.35 imp Edit src/sys/netinet6/scope6.c Add delta 1.12 2005.01.07.02.30.35 imp Edit src/sys/netinet6/scope6_var.h Add delta 1.4 2005.01.07.02.30.35 imp Edit src/sys/netinet6/udp6_output.c Add delta 1.19.2.3 2005.11.04.19.59.55 ume Add delta 1.19.2.2 2005.11.04.19.57.31 ume Add delta 1.19.2.1 2005.10.09.06.51.11 ume Edit src/sys/netinet6/udp6_usrreq.c Add delta 1.54 2005.06.01.11.38.19 rwatson Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 06:10:04 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 542F816A41F for ; Tue, 8 Nov 2005 06:10:04 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83FAD43D49 for ; Tue, 8 Nov 2005 06:10:03 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 4ABDC4CC4B; Tue, 8 Nov 2005 06:10:13 +0000 (GMT) Received: from [192.168.46.52] (ppp166-27.static.internode.on.net [150.101.166.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 52F4C4CBF1; Tue, 8 Nov 2005 06:10:12 +0000 (GMT) Message-ID: <43704138.2060007@roq.com> Date: Tue, 08 Nov 2005 17:10:00 +1100 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Isley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 06:10:04 -0000 I am having similar problems on a Dell 2850 using 6.0R AMD64, but I believe its not something to do with my hardware although I don't have any other AMD64/EMT64 server to test on. I don't think I have actually done a ISO install via serial console on 6.0-Release but I think I did on beta versions and it did work. I have been trying to do a PXE install and watching it all via serial console and it works fine as long as I dont use 6.0-Release files. Using a 6.0beta with PXE is working it fully boots the kernel and brings up sysinstall my only problem now is that when it tries to do a FTP install it goes for a 6.0beta5 directory which doesn't exist. When I try to use a 6.0-Release I can get it to boot loader and then get it to load the kernel but after that it disappears don't get any boot messages at all. Mike Jan Isley wrote: >Trying to install amd64 6.0 release on some Dells, PE850 and PE2850. >BIOS all setup same as what works just fine with 5.4 (both i386 and >amd64 cds). boot -h appears to work until it gets to the loader and >the console output goes to video. No keyboards or monitors plugged >in, just a serial console server. Have tried variations on serial >redirect in the BIOS but nothing seems to work. > >Anyone else have success or no with serial console redirect on amd64 6.0 cd? > >regards, >-Jan > > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 06:47:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CB016A41F for ; Tue, 8 Nov 2005 06:47:21 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EFFA43D49 for ; Tue, 8 Nov 2005 06:47:20 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1EZNFJ-0000Dm-PN; Tue, 08 Nov 2005 09:46:17 +0300 To: Michael VInce References: <43704138.2060007@roq.com> From: Boris Samorodov Date: Tue, 08 Nov 2005 09:46:17 +0300 In-Reply-To: <43704138.2060007@roq.com> (Michael VInce's message of "Tue, 08 Nov 2005 17:10:00 +1100") Message-ID: <27354694@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: Jan Isley , current@freebsd.org Subject: Re: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 06:47:21 -0000 On Tue, 08 Nov 2005 17:10:00 +1100 Michael VInce wrote: > I am having similar problems on a Dell 2850 using 6.0R AMD64, but I > believe its not something to do with my hardware although I don't have > any other AMD64/EMT64 server to test on. > I don't think I have actually done a ISO install via serial console on > 6.0-Release but I think I did on beta versions and it did work. > I have been trying to do a PXE install and watching it all via serial > console and it works fine as long as I dont use 6.0-Release > files. Using a 6.0beta with PXE is working it fully boots the kernel > and brings up sysinstall my only problem now is that when it tries to > do a FTP install it goes for a 6.0beta5 directory which doesn't You may change the version at Configure option at sysinstall Main Menu. Set the release name to 6.0-RELEASE. Then try to do an FTP-install. > exist. When I try to use a 6.0-Release I can get it to boot loader > and then get it to load the kernel but after that it disappears don't > get any boot messages at all. > Mike WBR -- Boris B. Samorodov, Research Engineer InPharmTech Co, http://www.ipt.ru Telephone & Internet Service Provider From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 07:40:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ECB016A420 for ; Tue, 8 Nov 2005 07:40:13 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: from web31803.mail.mud.yahoo.com (web31803.mail.mud.yahoo.com [68.142.207.66]) by mx1.FreeBSD.org (Postfix) with SMTP id 045F043D45 for ; Tue, 8 Nov 2005 07:40:11 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 60590 invoked by uid 60001); 8 Nov 2005 07:40:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kIzYhCV8wkCYiMZ9FNPXviGIUUXwI9O90R8uhFYpj8mABmxlYHc3n9npUD+zb1qK5z3FhQ069KyIKONynDdKX9NASzU7LznT4kMMnxIE8PgGY6b2EtqrCIF7L9Uwzg/1vkC4D7C9sBXAlhmawfuEcN2QB56AKkmGXeNiBAOgH1M= ; Message-ID: <20051108074011.60588.qmail@web31803.mail.mud.yahoo.com> Received: from [71.139.4.142] by web31803.mail.mud.yahoo.com via HTTP; Mon, 07 Nov 2005 23:40:11 PST Date: Mon, 7 Nov 2005 23:40:11 -0800 (PST) From: Mohan Srinivasan To: TOMITA Yoshinori , current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: FreeBSD 6.0 TCP NFS client stuck X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 07:40:13 -0000 Great. I'll commit the fix to current shortly and it will get MFC'ed to the 6.x branch soon. thanks ! mohan --- TOMITA Yoshinori wrote: > Thanks, Mohan. > > With your patch, it seems working fine. > > I could confirm FreeBSD6 NFS client will create a new TCP connection > and old session was cleaned up. > > > [tcpdump log] > > 15:36:48.138599 IP CLIENT.3523215360 > SERVER.nfs: 40 null > 15:36:48.138832 IP SERVER.nfs > CLIENT.3523215360: reply ok 24 null > 15:36:49.188099 IP SERVER.nfsd > CLIENT.706: F 86953281:86953281(0) ack 61240098 win 10136 > > 15:36:49.188169 IP CLIENT.706 > SERVER.nfsd: . ack 1 win 65535 797285900> > > *closed* > > 15:37:18.148158 IP CLIENT.3791650816 > SERVER.nfs: 40 null > 15:37:18.148393 IP SERVER.nfs > CLIENT.3791650816: reply ok 24 null > 15:37:48.157804 IP CLIENT.4060086272 > SERVER.nfs: 40 null > 15:37:48.158054 IP SERVER.nfs > CLIENT.4060086272: reply ok 24 null > > *try NFS access* > > 15:38:02.734963 IP CLIENT.2121656486 > SERVER.nfs: 132 access [|nfs] > 15:38:02.735001 IP CLIENT.706 > SERVER.nfsd: F 133:133(0) ack 1 win 65535 558510 797285900> > 15:38:02.735127 IP CLIENT.3946253056 > SERVER.nfs: 0 proc-215011 > 15:38:02.735211 IP SERVER.nfsd > CLIENT.706: . ack 134 win 10136 558509> > 15:38:02.735354 IP SERVER.nfs > CLIENT.3560442624: reply ERR 0 > 15:38:02.735444 IP CLIENT.980 > SERVER.nfsd: . ack 169844227 win 33304 797293252> > 15:38:02.735508 IP CLIENT.2121656486 > SERVER.nfs: 132 access [|nfs] > 15:38:02.735698 IP SERVER.nfsd > CLIENT.980: . ack 132 win 10004 558510> > 15:38:02.737331 IP SERVER.nfs > CLIENT.2121656486: reply ok 124 access [|nfs] > 15:38:02.739255 IP CLIENT.2121656493 > SERVER.nfs: 132 access [|nfs] > 15:38:02.739477 IP SERVER.nfsd > CLIENT.980: . ack 264 win 10136 558514> > 15:38:02.739612 IP SERVER.nfs > CLIENT.2121656493: reply ok 124 access [|nfs] > 15:38:02.739971 IP CLIENT.2121656494 > SERVER.nfs: 128 fsstat [|nfs] > 15:38:02.740322 IP SERVER.nfs > CLIENT.2121656494: reply ok 172 fsstat [|nfs] > 15:38:02.740553 IP CLIENT.2121656495 > SERVER.nfs: 148 readdir [|nfs] > 15:38:02.741950 IP SERVER.nfs > CLIENT.2121656495: reply ok 1448 readdir [|nfs] > 15:38:02.742072 IP SERVER.nfs > CLIENT.0: reply ERR 1448 > 15:38:02.742132 IP CLIENT.980 > SERVER.nfsd: . ack 3317 win 64906 797293252> > 15:38:02.742192 IP SERVER.nfs > CLIENT.1: reply ERR 1448 > 15:38:02.742315 IP SERVER.nfs > CLIENT.2316: reply ok 1448 > 15:38:02.742370 IP CLIENT.980 > SERVER.nfsd: . ack 6213 win 63458 797293252> > 15:38:02.742639 IP SERVER.nfs > CLIENT.779122034: reply ERR 1448 > 15:38:02.742724 IP SERVER.nfs > CLIENT.4020: reply ok 952 > 15:38:02.742787 IP CLIENT.980 > SERVER.nfsd: . ack 8613 win 65535 797293252> > 15:38:02.743621 IP CLIENT.2121656496 > SERVER.nfs: 148 readdir [|nfs] > 15:38:02.744928 IP SERVER.nfs > CLIENT.2121656496: reply ok 1448 readdir [|nfs] > 15:38:02.745043 IP SERVER.nfs > CLIENT.777151841: reply ERR 1448 > 15:38:02.745103 IP CLIENT.980 > SERVER.nfsd: . ack 11509 win 64906 797293253> > ...snip... > > > > [netstat at NFS server] > > 1. first time > > SERVER.nfsd CLIENT.706 131070 0 10136 0 ESTABLISHED > > 2. closed > > SERVER.nfsd CLIENT.706 131070 0 10136 0 FIN_WAIT_2 > > 3. after reconnect > > SERVER.nfsd CLIENT.706 131070 0 10136 0 TIME_WAIT > SERVER.nfsd CLIENT.980 131070 0 10136 0 ESTABLISHED > > > >> On Mon, 7 Nov 2005 21:41:22 -0800 (PST), Mohan Srinivasan said: > > M> Hi, > M> Can you try the change attached below and tell me if it > M> fixes your problem ? Sorry, I haven't tested this change > M> (I don't have a Solaris server handy to test against and > M> would have to hack the FreeBSD server to close down the > M> connection after a period of inactivity, like Solaris seems > M> to do). > > M> The change should cause the client to detect that the > M> server has FIN'ed, and should force a reconnect. Let me > M> know if this works for you and I will commit. > > M> thanks > > M> mohan > > M> ==== //depot/yahoo/ybsd_6/src/sys/nfsclient/nfs_socket.c#10 - /homes/mohans/p4/yahoo/ybsd > M> _6/src/sys/nfsclient/nfs_socket.c ==== > M> @@ -521,6 +521,17 @@ > M> return (error); > M> } > > M> +static inline int > M> +nfs_cantrecvmore(struct socket *so) > M> +{ > M> + int ret; > M> + > M> + SOCKBUF_LOCK(&so->so_rcv); > M> + ret = (so->so_rcv.sb_state & SBS_CANTRCVMORE); > M> + SOCKBUF_UNLOCK(&so->so_rcv); > M> + return ret; > M> +} > M> + > M> int > M> nfs_reply(struct nfsreq *rep) > M> { > M> @@ -550,7 +561,7 @@ > M> } > M> so = rep->r_nmp->nm_so; > M> mtx_lock(&rep->r_nmp->nm_nfstcpstate.mtx); > M> - if (!so || > M> + if (!so || nfs_cantrecvmore(so) || > M> (rep->r_nmp->nm_nfstcpstate.flags & NFS_TCP_FORCE_RECONNECT)) { > M> mtx_unlock(&rep->r_nmp->nm_nfstcpstate.mtx); > M> error = nfs_reconnect(rep); > > > M> --- TOMITA Yoshinori wrote: > > >> I saw a NFS client of FreeBSD 6.0-RC1 gets NFS stuck using TCP NFS and > >> amd -w LARGE_NUMBER, where -w specifies dismount interval such as > >> 3600. > >> > >> 6.0-STABLE cvsuped 2005-11-7 has same problem. > >> It has always been OK on FreeBSD 4.X to 5.4-STABLE. > >> > >> FreeBSD 6.0 NFS client seems keep trying NFS access forever after NFS > >> TCP connection is (half?) closed. > >> > >> I am not sure amd and -w argument are the key of this problem, but they > >> raise probability from my experience. > >> > >> > >> > >> NFS Server: > >> Solaris 2.6 > >> > >> NFS Client: > >> FreeBSD 6.0-RC1 (cvsuped 2005-11-02) > >> > >> Starting amd at FreeBSD: > >> /usr/sbin/amd -p -w 3600 -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map > >> > >> /etc/amd.map: > >> # changed proto=udp to proto=tcp > >> ------ > >> /defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key} > >> * opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev > >> ------ > >> > >> > >> > >> tcpdump log: > >> -------------------------------------------------- > >> > >> [several minutes passed after NFS auto-mounted] > >> > >> 11:09:38.852928 IP CLIENT.3254779904 > SERVER.nfs: 40 null > >> 11:09:38.853261 IP SERVER.nfs > CLIENT.3254779904: reply ok 24 null > >> 11:10:08.851290 IP CLIENT.3523215360 > SERVER.nfs: 40 null > >> 11:10:08.851529 IP SERVER.nfs > CLIENT.3523215360: reply ok 24 null > >> > >> [FIN from NFS server, FreeBSD NFS client sends ACK] > >> > >> 11:10:08.854469 IP SERVER.nfsd > CLIENT.820: F 341:341(0) ack 200 win 10136 > >> 787046144 183809> > >> 11:10:08.854555 IP CLIENT.820 > SERVER.nfsd: . ack 342 win 65535 787046144> > >> 11:10:08.864321 IP SERVER.nfsd > CLIENT.679: F 341:341(0) ack 200 win 10136 > >> 787046145 183817> > >> 11:10:08.864383 IP CLIENT.679 > SERVER.nfsd: . ack 342 win 65535 787046145> > >> 11:10:08.895133 IP SERVER.nfsd > CLIENT.735: F 40141:40141(0) ack 1900 win 10136 > >> > >> 11:10:08.895203 IP CLIENT.735 > SERVER.nfsd: . ack 40142 win 65535 787046148> > >> > >> [still NFS NULL continues from FreeBSD NFS client] > >> > >> 11:10:38.849614 IP CLIENT.3791650816 > SERVER.nfs: 40 null > >> 11:10:38.849906 IP SERVER.nfs > CLIENT.3791650816: reply ok 24 null > >> 11:11:08.847947 IP CLIENT.4060086272 > SERVER.nfs: 40 null > >> 11:11:08.848289 IP SERVER.nfs > CLIENT.4060086272: reply ok 24 null > >> 11:11:38.846275 IP CLIENT.33619968 > SERVER.nfs: 40 null > >> 11:11:38.846555 IP SERVER.nfs > CLIENT.33619968: reply ok 24 null > >> > >> [do some NFS access, such as /bin/ls /host/SERVER/SOMEWHERE on FreeBSD] > >> > >> 11:12:08.413414 IP CLIENT.302055424 > SERVER.nfs: 40 null > >> 11:12:08.413797 IP SERVER.nfs > CLIENT.302055424: reply ok 24 null > >> 11:12:08.414096 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:08.507632 IP SERVER.nfsd > CLIENT.735: . ack 2032 win 10136 787058109 > 663316> > >> 11:12:10.083443 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:10.177666 IP SERVER.nfsd > CLIENT.735: . ack 2164 win 10136 787058276 > 664986> > >> 11:12:11.743299 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:11.837696 IP SERVER.nfsd > CLIENT.735: . ack 2296 win 10136 787058442 > 666646> > >> 11:12:15.063018 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:15.157790 IP SERVER.nfsd > CLIENT.735: . ack 2428 win 10136 787058774 > 669966> > >> 11:12:21.702417 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:21.798028 IP SERVER.nfsd > CLIENT.735: . ack 2560 win 10136 787059438 > 676606> > >> 11:12:34.981251 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> 11:12:35.078429 IP SERVER.nfsd > CLIENT.735: . ack 2692 win 10136 787060766 > 689886> > >> 11:12:38.411967 IP CLIENT.570490880 > SERVER.nfs: 40 null > >> 11:12:38.412267 IP SERVER.nfs > CLIENT.570490880: reply ok 24 null > >> 11:13:01.538891 IP CLIENT.1563723127 > SERVER.nfs: 132 access [|nfs] > >> > >> [----> message repeats on FreeBSD NFS client] > >> nfs server SERVER:/export/home: not responding > >> > >> -------------------------------------------------- > >> > >> [netstat @ Solaris NFS server, when NFS is OK] > >> > >> SERVER.nfsd CLIENT.820 131070 0 10136 0 ESTABLISHED > >> SERVER.nfsd CLIENT.735 131070 0 10136 0 ESTABLISHED > >> SERVER.nfsd CLIENT.679 131070 0 10136 0 ESTABLISHED > >> > >> [after NFS stuck] > >> > >> SERVER.nfsd CLIENT.820 131070 0 10136 0 FIN_WAIT_2 > >> SERVER.nfsd CLIENT.735 131070 0 10136 0 FIN_WAIT_2 > >> SERVER.nfsd CLIENT.679 131070 0 10136 0 FIN_WAIT_2 > >> > >> [netstat @ FreeBSD NFS client, after NFS stuck] > >> > >> tcp4 0 0 CLIENT.679 SERVER.nfsd CLOSE_WAIT > >> tcp4 0 0 CLIENT.735 SERVER.nfsd CLOSE_WAIT > >> tcp4 0 0 CLIENT.820 SERVER.nfsd CLOSE_WAIT > >> > >> > >> -- > >> --- > >> TOMITA Yoshinori > >> (Fujitsu Laboratories Ltd., Kawasaki, Japan) > >> _______________________________________________ > >> 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" > >> > > > -- > --- > TOMITA Yoshinori > (Fujitsu Laboratories Ltd., Kawasaki, Japan) > From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 09:55:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C711116A41F for ; Tue, 8 Nov 2005 09:55:48 +0000 (GMT) (envelope-from nutbsd@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 518EF43D46 for ; Tue, 8 Nov 2005 09:55:48 +0000 (GMT) (envelope-from nutbsd@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so654300wxc for ; Tue, 08 Nov 2005 01:55:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=A9iUzj5TGe4e82sfuUFXxutsQGU8WcHlQwB6ItTUon3MPNghXcvPmrN4IWwsi0YDZR3aEtGPSgGh+gMt0/h2J8X7h58i4IkttUwId0CyeduAZbXdE5qUV7vKg50Fxh79BuMQyGbbrnGK6ceQ2xjLS/Uaz+VUvWM8lFI78su5aDQ= Received: by 10.70.15.10 with SMTP id 10mr6139694wxo; Tue, 08 Nov 2005 01:55:47 -0800 (PST) Received: by 10.70.37.6 with HTTP; Tue, 8 Nov 2005 01:55:47 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2005 17:55:47 +0800 From: Eric YU To: freebsd-current MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: xorg-printserver doesn't build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 09:55:48 -0000 uname -a FreeBSD tiger.co 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 I got these output when building xorg-printserver from ports: mifillrct.c:1:1: warning: null character(s) ignored mifillrct.c:112:38: unterminated argument list invoking macro "DEALLOCATE_LOCAL" mifillrct.c:111:38: warning: no newline at end of file mifillrct.c: In function `miPolyFillRect': mifillrct.c:111: error: syntax error at end of input mifillrct.c:75: warning: unused variable `height' mifillrct.c:76: warning: unused variable `width' mifillrct.c:82: warning: unused variable `ppt' mifillrct.c:84: warning: unused variable `pw' *** Error code 1 Stop in /usr/ports/x11-servers/xorg-printserver/work/xc/programs/Xserver/mi= . *** Error code 1 Stop in /usr/ports/x11-servers/xorg-printserver/work/xc/programs/Xserver. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 10:29:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7156716A421 for ; Tue, 8 Nov 2005 10:29:51 +0000 (GMT) (envelope-from creep@desk.pl) Received: from hera.desk.pl (hera.desk.pl [81.219.9.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EB143D46 for ; Tue, 8 Nov 2005 10:29:50 +0000 (GMT) (envelope-from creep@desk.pl) Received: from localhost (hera.local [127.0.0.1]) by hera.desk.pl (Postfix) with ESMTP id B8FC175C194 for ; Tue, 8 Nov 2005 11:30:22 +0100 (CET) Received: from hera.desk.pl ([127.0.0.1]) by localhost (hera [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27110-04 for ; Tue, 8 Nov 2005 11:30:20 +0100 (CET) Received: from webpoczta.desk.pl (hera [81.219.9.131]) by hera.desk.pl (Postfix) with SMTP id D343975C193 for ; Tue, 8 Nov 2005 11:30:20 +0100 (CET) Received: from 83.17.72.142 (WebPoczta DESK.pl account: creep@desk.pl) by webpoczta.desk.pl with HTTP; Tue, 8 Nov 2005 11:30:20 +0100 (CET) Message-ID: <52638.83.17.72.142.1131445820.WebPoczta@webpoczta.desk.pl> In-Reply-To: <200511071256.04488.jhb@freebsd.org> References: <436E66FB.60700@desk.pl> <200511071256.04488.jhb@freebsd.org> Date: Tue, 8 Nov 2005 11:30:20 +0100 (CET) From: creep@desk.pl To: freebsd-current@freebsd.org User-Agent: System Poczty DESK.pl/2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Antivirus: Skaner Antywirusowy DESK.pl Subject: Re: NVidia driver for amd64 / Page Attribute Table status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 10:29:51 -0000 > It's not finished, no. The WIP is being done in the p4_pat branch (though > it > has some crud in it now that probably isn't needed). For more info about > PAT > and memory caching modes on x86 including MTRR's, etc. you can go download > the vol 2 IA-32 arch PDF from developer.intel.com. It's not a conspiracy, > there are no black helicopters. Thanks for info, I'm sure there is no conspiracy in BSD developement, but they sure keep they heads down in the nVidia camp. I mainly asked what are the limitations of FreeBSD which block nvidia amd64 driver. It was nowhere explicitly said that PAT is to blame. If this feature is finished, can we expect the driver from nvidia? m. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 10:56:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A23D16A41F for ; Tue, 8 Nov 2005 10:56:04 +0000 (GMT) (envelope-from Tobias.Kilb@t-online.de) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CE2743D45 for ; Tue, 8 Nov 2005 10:56:03 +0000 (GMT) (envelope-from Tobias.Kilb@t-online.de) Received: from fwd31.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1EZR90-0004nb-02; Tue, 08 Nov 2005 11:56:02 +0100 Received: from tobias.universum.local (bjqnwiZSweo-FeWHB0i00l69rGkjqokIWXYyKR+yTWQVPXZnRhJQUn@[84.177.213.59]) by fwd31.sul.t-online.de with smtp id 1EZR8q-1qOtW40; Tue, 8 Nov 2005 11:55:52 +0100 Date: Tue, 8 Nov 2005 11:55:48 +0100 From: Tobias Kilb To: freebsd-current@freebsd.org Message-Id: <20051108115548.5ecbb2e5.Tobias.Kilb@t-online.de> In-Reply-To: <200511071637.55082.jhb@freebsd.org> References: <436FBD99.20009@fsklaw.com> <200511071637.55082.jhb@freebsd.org> X-Mailer: Sylpheed version 2.0.3 (GTK+ 2.8.6; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__8_Nov_2005_11_55_49_+0100_351Mu6QfRWB43QVb" X-ID: bjqnwiZSweo-FeWHB0i00l69rGkjqokIWXYyKR+yTWQVPXZnRhJQUn X-TOI-MSGID: a3b6fdf8-0b0d-4e0c-a53f-c632d73fa33e Subject: Re: FBSD 6.0 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 10:56:04 -0000 --Signature=_Tue__8_Nov_2005_11_55_49_+0100_351Mu6QfRWB43QVb Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 7 Nov 2005 16:37:53 -0500 John Baldwin wrote: > On Monday 07 November 2005 03:48 pm, Thomas M. Skeren III wrote: > > I cannot get an ISO to boot into the installer. I have tried 3 > > different AMD machines, an older Athlon 2000 with VIA chipset, a new > > Athlon 64x2 with NForce4 chipset, and an AMD64 Compaq laptop. All > > machines reboot after selecting either option 1 or 2. Both desktop > > machines have no problem with 5.4. > > > > What gives? >=20 > We need some more details. Does it print anything on the screen before i= t=20 > reboots? It would be especially helpful if you could hook up a serial=20 > console to capture any messages printed out before the reboot. >=20 You can check the *.iso files with "md5 FreeBSD6-blablubb.iso". On the Freebsd website is the original md5sum printed.=20 Tobias Kilb --=20 PGP Fingerprint: 8020 C7C0 3574 111C 8EA0 2BE9 7581 220C 1AC0 225B PGP Key ID: 0x1AC0225B=20 --Signature=_Tue__8_Nov_2005_11_55_49_+0100_351Mu6QfRWB43QVb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFDcIQ5dYEiDBrAIlsRAofrAJ48rDU935rB7nks5/5hc/zKE7IV8gCePmqd 30AHme+rjmc66GCqEYT8lvs= =H122 -----END PGP SIGNATURE----- --Signature=_Tue__8_Nov_2005_11_55_49_+0100_351Mu6QfRWB43QVb-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 10:58:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7D0316A41F for ; Tue, 8 Nov 2005 10:58:49 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from mail.loquefaltaba.com (78.Red-213-96-97.staticIP.rima-tde.net [213.96.97.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 152AF43D46 for ; Tue, 8 Nov 2005 10:58:49 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from localhost (localhost.loquefaltaba.com [127.0.0.1]) by mail.loquefaltaba.com (Postfix) with ESMTP id 044E1C1C5 for ; Tue, 8 Nov 2005 11:58:48 +0100 (CET) Received: from mail.loquefaltaba.com ([127.0.0.1]) by localhost (sico.loquefaltaba.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23503-02 for ; Tue, 8 Nov 2005 11:58:38 +0100 (CET) Received: from webmail.loquefaltaba.com (localhost.loquefaltaba.com [127.0.0.1]) by mail.loquefaltaba.com (Postfix) with ESMTP id BB15EC16F for ; Tue, 8 Nov 2005 11:58:38 +0100 (CET) Received: from qualityobjects.com ([213.37.252.198]) (SquirrelMail authenticated user sico) by webmail.loquefaltaba.com with HTTP; Tue, 8 Nov 2005 11:58:38 +0100 (CET) Message-ID: <54559.213.37.252.198.1131447518.squirrel@webmail.loquefaltaba.com> Date: Tue, 8 Nov 2005 11:58:38 +0100 (CET) From: "David Barbero" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at loquefaltaba.com Subject: panic and freeze in 6.0Release on Enterprise 450 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 10:58:49 -0000 Hello all. I am experiencing problems in a Enterprise 450 with 6.0Release. When I start with kernel without of_console and with, when the kernel use of_console does not give to an error of "jump to memory memory_direction" and the machine is freeze. When I qualify of_console begins to start correctly and when it initiates the network are times that remains freeze the machine and others gives linpanic when it takes another interface that is not hme, I have proven with several cards, two Realtek and one 3com. Has passed him this to somebody but? Regards. -- "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 12:11:42 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC64916A41F for ; Tue, 8 Nov 2005 12:11:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC0B43D53 for ; Tue, 8 Nov 2005 12:11:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 569EDCB; Tue, 8 Nov 2005 07:08:41 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 27233F0A; Tue, 8 Nov 2005 07:08:39 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EZSKA-000FLp-Tu; Tue, 08 Nov 2005 12:11:38 +0000 Date: Tue, 8 Nov 2005 12:11:38 +0000 From: Brian Candler To: "Thomas M. Skeren III" Message-ID: <20051108121138.GA58984@uk.tiscali.com> References: <436FBD99.20009@fsklaw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436FBD99.20009@fsklaw.com> User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org Subject: Re: FBSD 6.0 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 12:11:42 -0000 On Mon, Nov 07, 2005 at 12:48:25PM -0800, Thomas M. Skeren III wrote: > P.S. I re-downloaded the ISO image, just to see if I had a bad ISO. > Same thing. Just to be sure, I'd recommend you do md5 .iso and compare what you get with what the CHECKSUM.MD5 file says for your release. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:23:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA27716A41F for ; Tue, 8 Nov 2005 13:23:43 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EC1443D46 for ; Tue, 8 Nov 2005 13:23:41 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 8097 invoked from network); 8 Nov 2005 13:23:40 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 8 Nov 2005 13:23:40 -0000 Message-ID: <4370A6DC.80906@redstarling.com> Date: Tue, 08 Nov 2005 21:23:40 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 13:23:44 -0000 Does anyone have the latest compiled driver, twa.ko, for the 9550SX on freeBSD 6 amd64? I have a problem where I cannot compile the driver without installing freeBSD 6 to my new server and cannot install to the server without the compiled driver. The source can be downloaded from a link at the end of this page: http://www.3ware.com/KB/article.aspx?id=14546 thanks, ke han From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:37:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 692E416A41F for ; Tue, 8 Nov 2005 13:37:34 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EA1443D5D for ; Tue, 8 Nov 2005 13:37:27 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZTce-0002NC-5v for freebsd-current@freebsd.org; Tue, 08 Nov 2005 14:34:48 +0100 Received: from 72.11.2.113 ([72.11.2.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 14:34:48 +0100 Received: from lynnr.junk by 72.11.2.113 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 14:34:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Lynn A. Roth" Date: Tue, 08 Nov 2005 08:34:02 -0500 Lines: 32 Message-ID: References: <200511071835.jA7IZHuV081505@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 72.11.2.113 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en In-Reply-To: <200511071835.jA7IZHuV081505@ambrisko.com> Sender: news Subject: Re: Problems Installing to PowerEdge 850 with SATA Drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 13:37:34 -0000 Doug Ambrisko wrote: > Doug Ambrisko writes: > | Doug Ambrisko writes: > | | Lynn A. Roth writes: > | | | I have two new Dell Poweredge 850 machines. They have an Intel ICH7 > | | | chipset. When I boot FreeBSD 6 RC1, the controller is identified, but > | | | any drives connected to the SATA ports are not detected. The drive that > | | | is included with the system is a Seagate 7200.7 drive. I also tried a > | | | Maxtor. > | | > | | I can confirm the problem on the PE850. I have it working with my > | | latest 4.X SATA patches (which I haven't published yet). I might > | | be able to look into this. > | | > > Here's a hack to make it work on PE850: > > > This works for me on my PE850. It shouldn't break other stuff etc. > I assume the ICH6 will need the same type of change. > > Doug A. Thanks for this patch. Scott from pfSense integrated this into his kernel and it worked great for me. Thanks again. Lynn Roth Interactive Financial Solutions, Inc. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 13:47:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820F416A425 for ; Tue, 8 Nov 2005 13:47:22 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 2730643D45 for ; Tue, 8 Nov 2005 13:47:22 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 43598 invoked from network); 8 Nov 2005 13:47:21 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 8 Nov 2005 13:47:21 -0000 Message-ID: <4370AC6A.1010804@redstarling.com> Date: Tue, 08 Nov 2005 21:47:22 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: install problems for freeBSD 6 on tyan i7520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 13:47:22 -0000 I have a new server built around the Tyan i7520 motherboard. I am having a tremendously difficult time getting freeBSD 6 to find a hard drive to install to. I have a floppy connected to the mainboard through a separate controller and a CD connected through a separate controller channel. This is standard for this board. I have tried many scenarios for connecting a single hard drive, such as: 1 - running the system with just one EIDE hard drive (+ floppy and CD) connected to the motherboard PATA controller. 2 - running the system with just one SATA hard drive (+ floppy and CD) connected to the motherboard SATA controller. In all cases (with many tries of different BIOS settings), the freeBSD installer always says it cannot find a hard drive. The BIOS sees it. The boot loader sees it. When I run lsdev from the phase 3 prompt, the drives seem to be there named just as the boot loader and BIOS see them. I just don't get it!!!! The installer seems brain dead. Yes, the hardware works. Installing Centos 4.2 and Windows 2003 Server works perfect in all these configurations. Here are a few other oddities: 1 - The floppy drive is only recognized (for kld load) if I disable the BIOS onboard SATA. This is very odd. I need the floppy to load drivers like the 3ware 9550sx controller. 2 - If I go into phase 3 boot loader prompt, lsdev shows various drives I may have plugged in. lsdev seems correct and matches the BIOS...but the installer still says I have no hard disk to install to. My ultimate goal is to install to an array from my 3ware 9550sx controller. But I have scaled back this goal and unplugged the 3ware card for all the above tests. I have tried various phase 3 commands such as: set hint.fdc.0.flags="1" load atadisk set hint.acpi.0.disabled="1" Any ideas??? I have become the laughing stock of my office for continuing down the freeBSD route when Linux installs like a charm. thanks, ke han From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:11:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4389516A420; Tue, 8 Nov 2005 16:11:09 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A41143D53; Tue, 8 Nov 2005 16:10:59 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1586401 for multiple; Tue, 08 Nov 2005 11:13:00 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8GAjf5027042; Tue, 8 Nov 2005 11:10:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Vaibhave Agarwal Date: Tue, 8 Nov 2005 10:18:51 -0500 User-Agent: KMail/1.8.2 References: <20051027233636.GA39380@dmw.hopto.org> <200511071105.58729.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081018.53452.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-net@freebsd.org, freebsd-acpi@freebsd.org, current@freebsd.org, Nate Lawson Subject: Re: Freebsd 6.0 doesnt detect local APIC on a Pentium 3 machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:11:09 -0000 On Monday 07 November 2005 08:38 pm, Vaibhave Agarwal wrote: > On Mon, 7 Nov 2005, John Baldwin wrote: > > And even then it can't be used for any device interrupts since there > > aren't any I/O APICs. On a UP machine without I/O APICs, it's actually > > probably more optimal to just use irq0 and irq8 for clocks rather than > > the lapic timer anyway. The only real possible gain is the ability to > > use the profiling interrupt from the local APIC. > > I got access to the BIOS of the Pentium 3 machine I am using, but it has > no option to enable/disable the local APIC. Yes, I've not seen any BIOSen that do. > Joseph Koshy is right, Linux enables the local APIC timer while booting > up. I got the following in the bootup log of Linux 2.4 kernel on the same > machine. > > ------------------------- > Local APIC disabled by BIOS -- reenabling. > Found and enabled local APIC! > > Using local APIC timer interrupts. > calibrating APIC timer ... > ------------------------- Just because Linux does for UP doesn't mean it is more optimal for FreeBSD. :) On FreeBSD with the lapic timer you have 2 * hz interrupts per second. With the irq0/irq8 combo you have hz + stathz interrupts per second. The difference is 2000 vs 1128. Granted, the lapic timer interrupt handler doesn't have to talk to hardware out on the LPC bus.. > Though there is no I/O apic in the UP machines, but I only wanted to use > local APIC timer in the lapic_timer_oneshot() mode to schedule few timers > accurately. You can increase the rate of the rtc timer. We run it at profhz (1024) when profiling is enabled for example. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:11:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575AD16A420 for ; Tue, 8 Nov 2005 16:11:11 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id A419943D7B for ; Tue, 8 Nov 2005 16:10:59 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1586406 for multiple; Tue, 08 Nov 2005 11:13:03 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8GAjf6027042; Tue, 8 Nov 2005 11:10:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 10:24:44 -0500 User-Agent: KMail/1.8.2 References: <436E66FB.60700@desk.pl> <200511071256.04488.jhb@freebsd.org> <52638.83.17.72.142.1131445820.WebPoczta@webpoczta.desk.pl> In-Reply-To: <52638.83.17.72.142.1131445820.WebPoczta@webpoczta.desk.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081024.45589.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: creep@desk.pl Subject: Re: NVidia driver for amd64 / Page Attribute Table status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:11:11 -0000 On Tuesday 08 November 2005 05:30 am, creep@desk.pl wrote: > > It's not finished, no. The WIP is being done in the p4_pat branch > > (though it > > has some crud in it now that probably isn't needed). For more info about > > PAT > > and memory caching modes on x86 including MTRR's, etc. you can go > > download the vol 2 IA-32 arch PDF from developer.intel.com. It's not a > > conspiracy, there are no black helicopters. > > Thanks for info, I'm sure there is no conspiracy in BSD developement, but > they sure keep they heads down in the nVidia camp. I mainly asked what are > the limitations of FreeBSD which block nvidia amd64 driver. It was nowhere > explicitly said that PAT is to blame. If this feature is finished, can we > expect the driver from nvidia? I think that is probably a safe assumption, but it would be within the restraints of their timelines. They have release schedules and timelines just like FreeBSD does, so it would probably not be available until the PAT stuff is available and working for at least one of their release cycles. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:11:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B956E16A422; Tue, 8 Nov 2005 16:11:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9234443D5D; Tue, 8 Nov 2005 16:11:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1586407 for multiple; Tue, 08 Nov 2005 11:13:06 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8GAjf7027042; Tue, 8 Nov 2005 11:10:59 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 10:26:24 -0500 User-Agent: KMail/1.8.2 References: <43704138.2060007@roq.com> In-Reply-To: <43704138.2060007@roq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081026.26576.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Michael VInce , Jan Isley , current@freebsd.org Subject: Re: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:11:16 -0000 On Tuesday 08 November 2005 01:10 am, Michael VInce wrote: > I am having similar problems on a Dell 2850 using 6.0R AMD64, but I > believe its not something to do with my hardware although I don't have > any other AMD64/EMT64 server to test on. > > I don't think I have actually done a ISO install via serial console on > 6.0-Release but I think I did on beta versions and it did work. > I have been trying to do a PXE install and watching it all via serial > console and it works fine as long as I dont use 6.0-Release files. Using > a 6.0beta with PXE is working it fully boots the kernel and brings up > sysinstall my only problem now is that when it tries to do a FTP install > it goes for a 6.0beta5 directory which doesn't exist. When I try to use > a 6.0-Release I can get it to boot loader and then get it to load the > kernel but after that it disappears don't get any boot messages at all. > > Mike Have you checked to see if there are any device hints at the loader prompt? It may be that /boot/device.hints is missing on the CD for some reason, and the serial console requires at least one hint to set the flags on sio0 to work properly. > Jan Isley wrote: > >Trying to install amd64 6.0 release on some Dells, PE850 and PE2850. > >BIOS all setup same as what works just fine with 5.4 (both i386 and > >amd64 cds). boot -h appears to work until it gets to the loader and > >the console output goes to video. No keyboards or monitors plugged > >in, just a serial console server. Have tried variations on serial > >redirect in the BIOS but nothing seems to work. > > > >Anyone else have success or no with serial console redirect on amd64 6.0 > > cd? > > > >regards, > >-Jan > > _______________________________________________ > 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 Tue Nov 8 16:11:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B956E16A422; Tue, 8 Nov 2005 16:11:15 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9234443D5D; Tue, 8 Nov 2005 16:11:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1586407 for multiple; Tue, 08 Nov 2005 11:13:06 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8GAjf7027042; Tue, 8 Nov 2005 11:10:59 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 10:26:24 -0500 User-Agent: KMail/1.8.2 References: <43704138.2060007@roq.com> In-Reply-To: <43704138.2060007@roq.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081026.26576.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Michael VInce , Jan Isley , current@freebsd.org Subject: Re: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:11:17 -0000 On Tuesday 08 November 2005 01:10 am, Michael VInce wrote: > I am having similar problems on a Dell 2850 using 6.0R AMD64, but I > believe its not something to do with my hardware although I don't have > any other AMD64/EMT64 server to test on. > > I don't think I have actually done a ISO install via serial console on > 6.0-Release but I think I did on beta versions and it did work. > I have been trying to do a PXE install and watching it all via serial > console and it works fine as long as I dont use 6.0-Release files. Using > a 6.0beta with PXE is working it fully boots the kernel and brings up > sysinstall my only problem now is that when it tries to do a FTP install > it goes for a 6.0beta5 directory which doesn't exist. When I try to use > a 6.0-Release I can get it to boot loader and then get it to load the > kernel but after that it disappears don't get any boot messages at all. > > Mike Have you checked to see if there are any device hints at the loader prompt? It may be that /boot/device.hints is missing on the CD for some reason, and the serial console requires at least one hint to set the flags on sio0 to work properly. > Jan Isley wrote: > >Trying to install amd64 6.0 release on some Dells, PE850 and PE2850. > >BIOS all setup same as what works just fine with 5.4 (both i386 and > >amd64 cds). boot -h appears to work until it gets to the loader and > >the console output goes to video. No keyboards or monitors plugged > >in, just a serial console server. Have tried variations on serial > >redirect in the BIOS but nothing seems to work. > > > >Anyone else have success or no with serial console redirect on amd64 6.0 > > cd? > > > >regards, > >-Jan > > _______________________________________________ > 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 Tue Nov 8 16:11:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCDA416A42B for ; Tue, 8 Nov 2005 16:11:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8C8343D53 for ; Tue, 8 Nov 2005 16:11:09 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1586412 for multiple; Tue, 08 Nov 2005 11:13:09 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8GAjf8027042; Tue, 8 Nov 2005 11:11:01 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 10:29:40 -0500 User-Agent: KMail/1.8.2 References: <4370AC6A.1010804@redstarling.com> In-Reply-To: <4370AC6A.1010804@redstarling.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081029.41520.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: "ke.han" Subject: Re: install problems for freeBSD 6 on tyan i7520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:11:18 -0000 On Tuesday 08 November 2005 08:47 am, ke.han wrote: > I have a new server built around the Tyan i7520 motherboard. I am > having a tremendously difficult time getting freeBSD 6 to find a hard > drive to install to. > I have a floppy connected to the mainboard through a separate controller > and a CD connected through a separate controller channel. This is > standard for this board. > > I have tried many scenarios for connecting a single hard drive, such as: > 1 - running the system with just one EIDE hard drive (+ floppy and CD) > connected to the motherboard PATA controller. > 2 - running the system with just one SATA hard drive (+ floppy and CD) > connected to the motherboard SATA controller. > > In all cases (with many tries of different BIOS settings), the freeBSD > installer always says it cannot find a hard drive. The BIOS sees it. > The boot loader sees it. When I run lsdev from the phase 3 prompt, the > drives seem to be there named just as the boot loader and BIOS see them. > I just don't get it!!!! The installer seems brain dead. > Yes, the hardware works. Installing Centos 4.2 and Windows 2003 Server > works perfect in all these configurations. lsdev in the loader uses the BIOS. The kernel is not able to use the BIOS to talk to drives. Can you hook up a serial console and capture verbose boot messages? We need some more details such as what kind of ATA controller you are trying to use. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:14:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D7C16A41F for ; Tue, 8 Nov 2005 16:14:43 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52BF43D73 for ; Tue, 8 Nov 2005 16:14:42 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EZW14-0002Uu-K2 for freebsd-current@freebsd.org; Tue, 08 Nov 2005 17:08:10 +0100 Received: from 72.11.2.113 ([72.11.2.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 17:08:10 +0100 Received: from lynnr.junk by 72.11.2.113 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Nov 2005 17:08:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Lynn A. Roth" Date: Tue, 08 Nov 2005 11:00:39 -0500 Lines: 37 Message-ID: References: <200511071835.jA7IZHuV081505@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 72.11.2.113 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en In-Reply-To: Sender: news Subject: Re: Problems Installing to PowerEdge 850 with SATA Drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:14:44 -0000 Lynn A. Roth wrote: > Doug Ambrisko wrote: > >> Doug Ambrisko writes: >> | Doug Ambrisko writes: >> | | Lynn A. Roth writes: >> | | | I have two new Dell Poweredge 850 machines. They have an Intel >> ICH7 | | | chipset. When I boot FreeBSD 6 RC1, the controller is >> identified, but | | | any drives connected to the SATA ports are not >> detected. The drive that | | | is included with the system is a >> Seagate 7200.7 drive. I also tried a | | | Maxtor. >> | | | | I can confirm the problem on the PE850. I have it working >> with my >> | | latest 4.X SATA patches (which I haven't published yet). I might >> | | be able to look into this. >> | | >> Here's a hack to make it work on PE850: >> > > >> >> This works for me on my PE850. It shouldn't break other stuff etc. >> I assume the ICH6 will need the same type of change. >> >> Doug A. > > > Thanks for this patch. > Scott from pfSense integrated this into his kernel and it worked great > for me. > > Thanks again. Can this be committed sometime to current? Lynn From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:24:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7695D16A41F for ; Tue, 8 Nov 2005 16:24:48 +0000 (GMT) (envelope-from nvidican@wmptl.com) Received: from wmptl.net (fw1.wmptl.com [216.8.159.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4A1843D67 for ; Tue, 8 Nov 2005 16:24:47 +0000 (GMT) (envelope-from nvidican@wmptl.com) Received: from [10.0.0.104] (r3140ca.wmptl.net [10.0.0.104]) by wmptl.net (8.13.1/8.13.1) with ESMTP id jA8GOspD062236; Tue, 8 Nov 2005 11:24:55 -0500 (EST) (envelope-from nvidican@wmptl.com) Message-ID: <4370D11F.3070306@wmptl.com> Date: Tue, 08 Nov 2005 11:23:59 -0500 From: Nathan Vidican User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.111 () RATWR10_MESSID X-Scanned-By: MIMEDefang 2.44 Cc: fbsdlists@gmail.com Subject: [Fwd: Re: USB 2.0 Support (re-post, more info)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:24:48 -0000 Any truth to the ehci(4) having stability problems in >= 6.0-RC1 ? Or has this only been a problem in 5.4-RELEASE or earlier? -------- Original Message -------- Subject: Re: USB 2.0 Support (re-post, more info) Date: Tue, 8 Nov 2005 09:46:20 -0500 From: Bob Johnson To: Nathan Vidican CC: questions@freebsd.org References: <4370B124.1010103@wmptl.com> On 11/8/05, Nathan Vidican wrote: > I tried plugging the device in to all four ports on the USB 2.0 PCI Card, to > no > avail, no device/event is registered. I read the manpage on usbd, and it > appears > to be monitoring/watching for devices. I connect the device to one of the > two > ports on the mainboard, and I get this: > > > uhub3: device problem (SET_ADDR_FAILED), disabling port 1 > umass0: Cypress Semiconductor USB2.0 Storage Device, rev 2.00/0.01, addr 2 > umass0: Get Max Lun not supported (STALLED) > umass0: at uhub0 port 1 (addr 2) disconnected > umass0: detached > umass0: Cypress Semiconductor USB2.0 Storage Device, rev 2.00/0.01, addr 2 > umass0: Get Max Lun not supported (STALLED) > da1 at umass-sim0 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI-0 device > da1: 1.000MB/s transfers > da1: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) > > Yet again, my transfer speed is limited to the USB 1.1 specification of this > > controller, and it's terribly slow to be pulling 100GB tar files off of :( USB 2.0 support is provided by the ehci(4) driver, which is not in a default install. It is also buggy, at least in 5.4-R. I use Firewire for large external drives. - Bob -- Nathan Vidican nvidican@wmptl.com Windsor Match Plate & Tool Ltd. http://www.wmptl.com/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 16:53:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B6A16A41F for ; Tue, 8 Nov 2005 16:53:12 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp102.biz.mail.mud.yahoo.com (smtp102.biz.mail.mud.yahoo.com [68.142.200.237]) by mx1.FreeBSD.org (Postfix) with SMTP id EF98C43D46 for ; Tue, 8 Nov 2005 16:53:11 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 49170 invoked from network); 8 Nov 2005 16:52:18 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 8 Nov 2005 16:52:18 -0000 Message-ID: <4370D7C0.8060109@redstarling.com> Date: Wed, 09 Nov 2005 00:52:16 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4370AC6A.1010804@redstarling.com> <200511081029.41520.jhb@freebsd.org> In-Reply-To: <200511081029.41520.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: install problems for freeBSD 6 on tyan i7520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 16:53:12 -0000 John Baldwin wrote: > On Tuesday 08 November 2005 08:47 am, ke.han wrote: >> > lsdev in the loader uses the BIOS. The kernel is not able to use the BIOS to > talk to drives. Can you hook up a serial console and capture verbose boot > messages? We need some more details such as what kind of ATA controller you > are trying to use. > The tyan i7520 specs are at: http://www.tyan.com/products/html/thunderi7520_spec.html I would love to capture more info and send it in. Sounds like I need a serial cable? Any specific pin arrangement? Is there a howto on this? I have a working laptop with freeBSD 6. Do I just connect the laptop to the server some way? thanks, ke han From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 17:18:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6625216A454 for ; Tue, 8 Nov 2005 17:18:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60FE243D6D for ; Tue, 8 Nov 2005 17:17:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1589994 for multiple; Tue, 08 Nov 2005 12:19:55 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA8HHglm027498; Tue, 8 Nov 2005 12:17:47 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "ke.han" Date: Tue, 8 Nov 2005 12:17:31 -0500 User-Agent: KMail/1.8.2 References: <4370AC6A.1010804@redstarling.com> <200511081029.41520.jhb@freebsd.org> <4370D7C0.8060109@redstarling.com> In-Reply-To: <4370D7C0.8060109@redstarling.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081217.32606.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: install problems for freeBSD 6 on tyan i7520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 17:18:01 -0000 On Tuesday 08 November 2005 11:52 am, ke.han wrote: > John Baldwin wrote: > > On Tuesday 08 November 2005 08:47 am, ke.han wrote: > > > > > > lsdev in the loader uses the BIOS. The kernel is not able to use the > > BIOS to talk to drives. Can you hook up a serial console and capture > > verbose boot messages? We need some more details such as what kind of > > ATA controller you are trying to use. > > The tyan i7520 specs are at: > http://www.tyan.com/products/html/thunderi7520_spec.html > > I would love to capture more info and send it in. Sounds like I need a > serial cable? Any specific pin arrangement? Is there a howto on this? > I have a working laptop with freeBSD 6. Do I just connect the laptop to > the server some way? Just a null modem cable would work fine. There's info in the handbook at www.freebsd.org on how to setup a serial console. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 18:01:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12C8816A41F for ; Tue, 8 Nov 2005 18:01:07 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from sdcexchange01.amcc.com (gatekeeper-out.amcc.com [198.137.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5963043D49 for ; Tue, 8 Nov 2005 18:01:05 +0000 (GMT) (envelope-from vkashyap@amcc.com) Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2005 10:00:56 -0800 Message-ID: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3ware 9550sx driver for freeBSD 6 amd64 ?? thread-index: AcXkZ3RhaSw5wYvZSv6aRVZqrjrjmAAJe8jA From: "Vinod Kashyap" To: "ke.han" , Cc: Subject: RE: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 18:01:07 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org=20 > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of ke.han > Sent: Tuesday, November 08, 2005 5:24 AM > To: freebsd-current@freebsd.org > Subject: 3ware 9550sx driver for freeBSD 6 amd64 ?? >=20 > Does anyone have the latest compiled driver, twa.ko, for the=20 > 9550SX on freeBSD 6 amd64? > I have a problem where I cannot compile the driver without=20 > installing freeBSD 6 to my new server and cannot install to=20 > the server without the compiled driver. > The source can be downloaded from a link at the end of this page: > http://www.3ware.com/KB/article.aspx?id=3D14546 >=20 The driver integrated into FreeBSD 6.0 does not know about SX controllers. So, you cannot install FreeBSD 6.0 on SX. For installation purposes, there are plans to provide an SX driver for 6.0 (and 5.4) which can be loaded from a floppy. -------------------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, = is for the sole use of the intended recipient(s) and contains = information that is confidential and proprietary to Applied Micro = Circuits Corporation or its subsidiaries. It is to be used solely for = the purpose of furthering the parties' business relationship. All = unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 18:13:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6729016A41F for ; Tue, 8 Nov 2005 18:13:27 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4E1043D45 for ; Tue, 8 Nov 2005 18:13:26 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp5-g19.free.fr (Postfix) with ESMTP id A66149823 for ; Tue, 8 Nov 2005 19:13:25 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA8IDLxC015777 for ; Tue, 8 Nov 2005 19:13:24 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 19:13:14 +0100 User-Agent: KMail/1.8.3 References: <20051107094655.GA76489@cirb503493.alcatel.com.au> In-Reply-To: <20051107094655.GA76489@cirb503493.alcatel.com.au> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511081913.15042.thierry@herbelot.com> Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 18:13:27 -0000 Le Monday 7 November 2005 10:46, Peter Jeremy a écrit : > > Tonight's problem was in -CURRENT from last Saturday night. A > backtrace is below. No crashdump (unfortunately) because the kernel > got into a loop of breakpoint instruction faults. That said, the > fault is fairly clearly the API bug that's mentioned in the above > reference. me too I also see this kind of panic : fwohci0: fwohci_pci_suspend panic: trying to sleep while sleeping is prohibited cpuid = 0 KDB: enter: panic [thread pid 29 tid 100036 ] Stopped at kdb_enter+0x2b: nop db> trace Tracing pid 29 tid 100036 td 0xc1f67d80 kdb_enter(c08709d0) at kdb_enter+0x2b panic(c08739d1,2,c1f67d80,3e,cb70da24) at panic+0x127 sleepq_add(c1e1d000,0,c085ca65,0) at sleepq_add+0x8c msleep(c1e1d000,0,54,c085ca65,190) at msleep+0x249 cbb_cardbus_reset(c1e53380,c1e53380,0,c1e53380,cb70da90) at cbb_cardbus_reset+0xf6 cbb_cardbus_power_disable_socket(c1e53380,c1f48680) at cbb_cardbus_power_disable_socket+0x15 cbb_power_disable_socket(c1e53380,c1f48680) at cbb_power_disable_socket+0x33 pccard_detach_card(c1f48680,cb70dad4,c065c52e,c1f48680,c1e56480) at pccard_detach_card+0xb4 pccard_suspend(c1f48680) at pccard_suspend+0xb bus_generic_suspend(c1e53380,c1e53380,c1f48700,c1e56480,c1e53380) at bus_generic_suspend+0x4a cbb_suspend(c1e53380) at cbb_suspend+0x59 bus_generic_suspend(c1e4c300,c08d23e8,c08d23e8,c1e4c300,c1dd2300) at bus_generic_suspend+0x4a pci_suspend(c1e4c300) at pci_suspend+0x7a bus_generic_suspend(c1dd2100) at bus_generic_suspend+0x4a bus_generic_suspend(c1dd2300,c093b540,1,c0b1d341,260) at bus_generic_suspend+0x4a acpi_suspend(c1dd2300) at acpi_suspend+0x28 bus_generic_suspend(c1dd2d00) at bus_generic_suspend+0x4a bus_generic_suspend(c1d6f000,3,1,101dc70,0) at bus_generic_suspend+0x4a acpi_SetSleepState(c1dd2080,3,0,cb70dc38,c0660a63) at acpi_SetSleepState+0x16a acpi_pm_func(0,c1dd2080,1,cb70dc80,c07e8d47) at acpi_pm_func+0x3a power_pm_suspend(1) at power_pm_suspend+0x23 scgetc(c1f88800,2,c0669865,c1e7a900,c0997fa0) at scgetc+0x4ef sckbdevent(c0997fa0,0,c1f88800) at sckbdevent+0x1c8 atkbd_intr(c0997fa0,0,cb70dcec,c0632c9a,c0997fa0) at atkbd_intr+0x20 atkbdintr(c0997fa0) at atkbdintr+0x16 ithread_execute_handlers(c1f66224,c1d54600) at ithread_execute_handlers+0xe6 ithread_loop(c1f6e1b0,cb70dd38,c1f6e1b0,c0632d64,0) at ithread_loop+0x67 fork_exit(c0632d64,c1f6e1b0,cb70dd38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcb70dd6c, ebp = 0 --- kgdb dump : (extract) #9 0xc06458c3 in panic (fmt=0xc08739d1 "trying to sleep while sleeping is prohibited") at /usr/src/sys/kern/kern_shutdown.c:539 #10 0xc0664a54 in sleepq_add (wchan=0xc1e1d000, lock=0x0, wmesg=0x12
, flags=0) at /usr/src/sys/kern/subr_sleepqueue.c:273 #11 0xc064b899 in msleep (ident=0xc1e1d000, mtx=0x0, priority=84, wmesg=0xc085ca65 "cbbP3", timo=400) at /usr/src/sys/kern/kern_synch.c:205 #12 0xc0585166 in cbb_cardbus_reset (brdev=0xc1e53380) at /usr/src/sys/dev/pccbb/pccbb.c:960 #13 0xc05852d5 in cbb_cardbus_power_disable_socket (brdev=0xc1e53380, child=0xc1f48680) at /usr/src/sys/dev/pccbb/pccbb.c:990 #14 0xc0585eeb in cbb_power_disable_socket (brdev=0xc1e53380, child=0xc1f48680) at /usr/src/sys/dev/pccbb/pccbb.c:1319 #15 0xc057e7a8 in pccard_detach_card (dev=0xc1f48680) at power_if.h:37 #16 0xc057f553 in pccard_suspend (self=0xc1f48680) at /usr/src/sys/dev/pccard/pccard.c:795 #17 0xc065c52e in bus_generic_suspend (dev=0xc1e53380) at device_if.h:272 #18 0xc0586575 in cbb_suspend (self=0xc1e53380) at /usr/src/sys/dev/pccbb/pccbb.c:1578 #19 0xc065c52e in bus_generic_suspend (dev=0xc1e4c300) at device_if.h:272 #20 0xc058ab2e in pci_suspend (dev=0xc1e4c300) at /usr/src/sys/dev/pci/pci.c:1130 #21 0xc065c52e in bus_generic_suspend (dev=0xc1dd2100) at device_if.h:272 #22 0xc065c52e in bus_generic_suspend (dev=0xc1dd2300) at device_if.h:272 idents : src/sys/kern/subr_sleepqueue.c,v 1.20 2005/10/31 15:41:25 rwatson Exp $ src/sys/kern/kern_synch.c,v 1.270 2005/05/23 23:01:52 ups Exp $ src/sys/dev/pccbb/pccbb.c,v 1.134 2005/10/29 03:36:00 imp Exp $ src/sys/dev/pccard/pccard.c,v 1.113 2005/09/22 14:51:11 imp Exp $ src/sys/dev/pci/pci.c,v 1.303 2005/10/29 05:52:17 imp Exp $ From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:06:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 009A116A41F for ; Tue, 8 Nov 2005 19:06:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EDC43D49 for ; Tue, 8 Nov 2005 19:06:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA8J55c1025828; Tue, 8 Nov 2005 12:05:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Nov 2005 12:05:36 -0700 (MST) Message-Id: <20051108.120536.90824853.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511081913.15042.thierry@herbelot.com> References: <20051107094655.GA76489@cirb503493.alcatel.com.au> <200511081913.15042.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 08 Nov 2005 12:05:07 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:06:51 -0000 In message: <200511081913.15042.thierry@herbelot.com> Thierry Herbelot writes: : I also see this kind of panic : : fwohci0: fwohci_pci_suspend : panic: trying to sleep while sleeping is prohibited The root of this problem is: ... : bus_generic_suspend(c1d6f000,3,1,101dc70,0) at bus_generic_suspend+0x4a : acpi_SetSleepState(c1dd2080,3,0,cb70dc38,c0660a63) at acpi_SetSleepState+0x16a : acpi_pm_func(0,c1dd2080,1,cb70dc80,c07e8d47) at acpi_pm_func+0x3a : power_pm_suspend(1) at power_pm_suspend+0x23 : scgetc(c1f88800,2,c0669865,c1e7a900,c0997fa0) at scgetc+0x4ef : sckbdevent(c0997fa0,0,c1f88800) at sckbdevent+0x1c8 : atkbd_intr(c0997fa0,0,cb70dcec,c0632c9a,c0997fa0) at atkbd_intr+0x20 : atkbdintr(c0997fa0) at atkbdintr+0x16 We're calling the entire suspend chain from an interrupt handler. Granted, this interrupt hanlder is in an ithread, but we still prohibit sleeping there. The solution is to have power_pm_suspend call the callback function using a taskqueue. Warner From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:13:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D2F316A41F; Tue, 8 Nov 2005 19:13:03 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 505F043D53; Tue, 8 Nov 2005 19:13:02 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3F9B6.dip.t-dialin.net [84.163.249.182] (helo=donor.laier.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1EZYtt3B7F-0004st; Tue, 08 Nov 2005 20:12:57 +0100 From: Max Laier To: Victor Snezhko Date: Tue, 8 Nov 2005 20:11:45 +0100 User-Agent: KMail/1.8.2 References: <20051027022313.R675@kushnir1.kiev.ua> <20051105213753.GB26532@lbl.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1151758.M3CCCGQkIu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200511082012.56306.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: kuba@lbl.pl, freebsd-current@freebsd.org Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:13:03 -0000 --nextPart1151758.M3CCCGQkIu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 06 November 2005 10:19, Victor Snezhko wrote: > KubaTyszko writes: > > hi. > > did we have that fixed or the bug already occurs ? > > Not yet. > I'm still trying to figure out what code corrupts the callwheel in > kern_timeout.c. > > I'm not a kernel guru so the progress is slow. Before we all lose track of it, please submit a PR with the details you hav= e=20 discovered so far: ln_timer_ch callout_stop()ed without being initialized -= =20 IIRC. Please inform me and/or suz@ about the PR# in order to get moving with it. = =20 Thanks! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1151758.M3CCCGQkIu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDcPi4XyyEoT62BG0RAsbIAJ9xnaDdvX7jslIdqClSvkuMQav2WACeKG7u MpJ2Zfa/R/pOzc3/VE+nIY8= =YOZ2 -----END PGP SIGNATURE----- --nextPart1151758.M3CCCGQkIu-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:18:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7276F16A41F for ; Tue, 8 Nov 2005 19:18:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0935243D48 for ; Tue, 8 Nov 2005 19:18:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA8JIRMD025931; Tue, 8 Nov 2005 12:18:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Nov 2005 12:18:58 -0700 (MST) Message-Id: <20051108.121858.51703736.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511081913.15042.thierry@herbelot.com> References: <20051107094655.GA76489@cirb503493.alcatel.com.au> <200511081913.15042.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 08 Nov 2005 12:18:27 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:18:34 -0000 Does this solve the problem? Warner Index: subr_power.c =================================================================== RCS file: /cache/ncvs/src/sys/kern/subr_power.c,v retrieving revision 1.5 diff -u -r1.5 subr_power.c --- subr_power.c 2 Jan 2004 18:24:13 -0000 1.5 +++ subr_power.c 8 Nov 2005 19:17:54 -0000 @@ -32,10 +32,20 @@ #include #include +#include static u_int power_pm_type = POWER_PM_TYPE_NONE; static power_pm_fn_t power_pm_fn = NULL; static void *power_pm_arg = NULL; +static struct task power_pm_task; + +static void +power_pm_deferred_fn(void *arg, int pending) +{ + int state = (int)arg; + + power_pm_fn(POWER_CMD_SUSPEND, power_pm_arg, state); +} int power_pm_register(u_int pm_type, power_pm_fn_t pm_fn, void *pm_arg) @@ -48,6 +58,7 @@ power_pm_fn = pm_fn; power_pm_arg = pm_arg; error = 0; + TASK_INIT(&power_pm_task, 0, power_pm_deferred_fn, NULL); } else { error = ENXIO; } @@ -72,8 +83,8 @@ state != POWER_SLEEP_STATE_SUSPEND && state != POWER_SLEEP_STATE_HIBERNATE) return; - - power_pm_fn(POWER_CMD_SUSPEND, power_pm_arg, state); + power_pm_task.ta_context = (void *)state; + taskqueue_enqueue(taskqueue_swi, &power_pm_task); } /* From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:32:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FB7C16A41F for ; Tue, 8 Nov 2005 19:32:30 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0BCD43D4C for ; Tue, 8 Nov 2005 19:32:29 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EZZCn-0002K1-Cy for freebsd-current@freebsd.org; Tue, 08 Nov 2005 19:32:29 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EZZCm-000JDq-4u for freebsd-current@freebsd.org; Tue, 08 Nov 2005 09:32:28 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17264.64843.738921.535657@roam.psg.com> Date: Tue, 8 Nov 2005 09:32:27 -1000 To: FreeBSD Current Subject: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:32:30 -0000 can't find an appropriate list, so i'll whine here. Connecting to cvsup10.freebsd.org Connected to cvsup10.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running TreeList failed: Network write failure: Connection closed this has been persistent for some hours randy From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:38:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFB2016A420 for ; Tue, 8 Nov 2005 19:38:27 +0000 (GMT) (envelope-from fbsdlists@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 823A743D45 for ; Tue, 8 Nov 2005 19:38:27 +0000 (GMT) (envelope-from fbsdlists@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so633805nzp for ; Tue, 08 Nov 2005 11:38:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XfpU2e3NzRIIoCj0owvl+ucJTsOqDRXRYwhsKk43buISzqT4hNwXQHfPK7v6BCtGq6KsLc6+M6Kjup7hb1Ts85dZ8b7w519gNVetZAO+dgwSXEn3dRIEhbSgTI/aBNJaPwnHwvWmgOQjdceDvGRSlqF2hAg2Dg4jr/4qmJC/LiE= Received: by 10.64.209.3 with SMTP id h3mr7004885qbg; Tue, 08 Nov 2005 11:38:27 -0800 (PST) Received: by 10.65.253.2 with HTTP; Tue, 8 Nov 2005 11:38:26 -0800 (PST) Message-ID: <54db43990511081138p86058bfrb5a9786261a0e6b2@mail.gmail.com> Date: Tue, 8 Nov 2005 14:38:26 -0500 From: Bob Johnson To: Nathan Vidican In-Reply-To: <4370D11F.3070306@wmptl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4370D11F.3070306@wmptl.com> Cc: current@freebsd.org Subject: Re: USB 2.0 Support (re-post, more info) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:38:28 -0000 On 11/8/05, Nathan Vidican wrote: > Any truth to the ehci(4) having stability problems in >=3D 6.0-RC1 ? Or h= as > this > only been a problem in 5.4-RELEASE or earlier? > Check the man page: in 5.4 it says the driver is very buggy, and I certainly wasn't able to use it on my laptop. I haven't tested 6.0 on my laptop yet. - Bob From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 19:43:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75B3B16A41F for ; Tue, 8 Nov 2005 19:43:03 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF39743D46 for ; Tue, 8 Nov 2005 19:43:02 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D559.dip.t-dialin.net [84.165.213.89]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id jA8JKjIj076340; Tue, 8 Nov 2005 20:20:45 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id jA8JguIo020029; Tue, 8 Nov 2005 20:42:57 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Tue, 8 Nov 2005 20:42:56 +0100 From: Alexander Leidinger To: Randy Bush Message-ID: <20051108204256.385b11fc@Magellan.Leidinger.net> In-Reply-To: <17264.64843.738921.535657@roam.psg.com> References: <17264.64843.738921.535657@roam.psg.com> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: FreeBSD Current Subject: Re: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 19:43:03 -0000 On Tue, 8 Nov 2005 09:32:27 -1000 Randy Bush wrote: > can't find an appropriate list, so i'll whine here. > > Connecting to cvsup10.freebsd.org > Connected to cvsup10.freebsd.org > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > TreeList failed: Network write failure: Connection closed > > this has been persistent for some hours This is a network problem. The connection was closed (e.g. the cleaning personel pulled the plug of the NIC by accident...). This problem can be on your end of the connection, on the cvsup10 side, or somewhere in between. Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:16:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89A3D16A420 for ; Tue, 8 Nov 2005 20:16:53 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A7E43D48 for ; Tue, 8 Nov 2005 20:16:50 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so810643wxc for ; Tue, 08 Nov 2005 12:16:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=MG6+1061IDZXW8qjDBO4xEa9SbyRE4ByL8lBc6um1SmxCwGler30vX96n8O4tJf69iYRwPg27HJDTkWYVfF9q2rEnl92hJ6YClcFCXjnzTykUmPwSqgk5IuoVYbjglC6tDqsO1qoDra5TU2Jw8dhngc/5oz1KbRtZvUG/MncPc8= Received: by 10.70.7.20 with SMTP id 20mr6716630wxg; Tue, 08 Nov 2005 11:49:39 -0800 (PST) Received: from ?192.168.1.10? ( [71.102.14.129]) by mx.gmail.com with ESMTP id i11sm1310021wxd.2005.11.08.11.49.36; Tue, 08 Nov 2005 11:49:39 -0800 (PST) From: "Michael C. Shultz" To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 11:40:53 -0800 User-Agent: KMail/1.8.3 References: <17264.64843.738921.535657@roam.psg.com> <20051108204256.385b11fc@Magellan.Leidinger.net> In-Reply-To: <20051108204256.385b11fc@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511081140.54930.ringworm01@gmail.com> Cc: Randy Bush , Alexander Leidinger Subject: Re: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 20:16:53 -0000 On Tuesday 08 November 2005 11:42, Alexander Leidinger wrote: > On Tue, 8 Nov 2005 09:32:27 -1000 > > Randy Bush wrote: > > can't find an appropriate list, so i'll whine here. > > > > Connecting to cvsup10.freebsd.org > > Connected to cvsup10.freebsd.org > > Server software version: SNAP_16_1h > > Negotiating file attribute support > > Exchanging collection information > > Establishing multiplexed-mode data connection > > Running > > TreeList failed: Network write failure: Connection closed > > > > this has been persistent for some hours > > This is a network problem. The connection was closed (e.g. the cleaning > personel pulled the plug of the NIC by accident...). > > This problem can be on your end of the connection, on the cvsup10 side, > or somewhere in between. > > Bye, > Alexander. I get the same error with that server, it is annoying. -Mike From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:29:37 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AD4416A41F for ; Tue, 8 Nov 2005 20:29:37 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18BD743D46 for ; Tue, 8 Nov 2005 20:29:36 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.0.94] (s1013-0185.dsl.start.no [195.159.204.217]) by smtp1.powertech.no (Postfix) with ESMTP id 27C8D7E47; Tue, 8 Nov 2005 21:29:35 +0100 (CET) In-Reply-To: <54db43990511081138p86058bfrb5a9786261a0e6b2@mail.gmail.com> References: <4370D11F.3070306@wmptl.com> <54db43990511081138p86058bfrb5a9786261a0e6b2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Frode Nordahl Date: Tue, 8 Nov 2005 21:29:36 +0100 To: Bob Johnson X-Mailer: Apple Mail (2.746.2) Cc: Nathan Vidican , current@freebsd.org Subject: Re: USB 2.0 Support (re-post, more info) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 20:29:37 -0000 On 8. nov. 2005, at 20.38, Bob Johnson wrote: > On 11/8/05, Nathan Vidican wrote: >> Any truth to the ehci(4) having stability problems in >= 6.0-RC1 ? >> Or has >> this >> only been a problem in 5.4-RELEASE or earlier? >> > > Check the man page: in 5.4 it says the driver is very buggy, and I > certainly wasn't able to use it on my laptop. I haven't tested 6.0 on > my laptop yet. FWIW, many problems I had with ehci(4) in 5.4 are now gone i 6.0- RELEASE. And the fact that it is now part of GENERIC should mean that the developers believe it has become more stable. I have not tested it extensively yet, but now I at least can boot a machine with a USB 2.0 drive connected without it hanging forever after "waiting for SCSI devices to settle". And it also works without disabling onboard USB 1.0 / USB 1.1. I have yet to test pulling mounted drives during I/O and other nasty stuff :-) Frode Nordahl frode@nordahl.net From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:43:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 602DD16A41F for ; Tue, 8 Nov 2005 20:43:42 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0657543D4C for ; Tue, 8 Nov 2005 20:43:41 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: by turing.cs.hmc.edu (Postfix, from userid 26983) id 501815325F; Tue, 8 Nov 2005 12:43:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by turing.cs.hmc.edu (Postfix) with ESMTP id 3A77C5A8DE; Tue, 8 Nov 2005 12:43:41 -0800 (PST) Date: Tue, 8 Nov 2005 12:43:41 -0800 (PST) From: Nate Eldredge X-X-Sender: nate@turing To: Alexander Leidinger In-Reply-To: <20051108204256.385b11fc@Magellan.Leidinger.net> Message-ID: References: <17264.64843.738921.535657@roam.psg.com> <20051108204256.385b11fc@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , FreeBSD Current Subject: Re: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 20:43:42 -0000 On Tue, 8 Nov 2005, Alexander Leidinger wrote: > On Tue, 8 Nov 2005 09:32:27 -1000 > Randy Bush wrote: > >> can't find an appropriate list, so i'll whine here. >> >> Connecting to cvsup10.freebsd.org >> Connected to cvsup10.freebsd.org >> Server software version: SNAP_16_1h >> Negotiating file attribute support >> Exchanging collection information >> Establishing multiplexed-mode data connection >> Running >> TreeList failed: Network write failure: Connection closed >> >> this has been persistent for some hours > > This is a network problem. The connection was closed (e.g. the cleaning > personel pulled the plug of the NIC by accident...). > > This problem can be on your end of the connection, on the cvsup10 side, > or somewhere in between. Maybe it's due to heavy server load? Since 6.0 was just released a couple days ago, there are probably a lot of people cvsup-ing it. You could try a different mirror or wait another couple of days. -- Nate Eldredge nge@cs.hmc.edu From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:48:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E9D716A420; Tue, 8 Nov 2005 20:48:16 +0000 (GMT) (envelope-from tim-lists@bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [84.234.16.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32BB143D46; Tue, 8 Nov 2005 20:48:15 +0000 (GMT) (envelope-from tim-lists@bishnet.net) Received: from inferno.sixth.bishnet.net ([82.68.45.195] helo=localhost.localdomain) by carrick.bishnet.net with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.54 (FreeBSD)) id 1EZaNn-000Bm4-Q1; Tue, 08 Nov 2005 20:47:55 +0000 From: Tim Bishop To: "Michael C. Shultz" In-Reply-To: <200511081140.54930.ringworm01@gmail.com> References: <17264.64843.738921.535657@roam.psg.com> <20051108204256.385b11fc@Magellan.Leidinger.net> <200511081140.54930.ringworm01@gmail.com> Content-Type: text/plain Date: Tue, 08 Nov 2005 20:48:51 +0000 Message-Id: <1131482931.22250.1.camel@inferno.sixth.bishnet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.495, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.90, BAYES_00 -2.60) X-Bishnet-MailScanner-From: tim-lists@bishnet.net Cc: Randy Bush , Alexander Leidinger , freebsd-hubs@freebsd.org, freebsd-current@freebsd.org Subject: Re: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 20:48:16 -0000 On Tue, 2005-11-08 at 11:40 -0800, Michael C. Shultz wrote: > On Tuesday 08 November 2005 11:42, Alexander Leidinger wrote: > > On Tue, 8 Nov 2005 09:32:27 -1000 > > Randy Bush wrote: > > > can't find an appropriate list, so i'll whine here. > > > > > > Connecting to cvsup10.freebsd.org > > > Connected to cvsup10.freebsd.org > > > Server software version: SNAP_16_1h > > > Negotiating file attribute support > > > Exchanging collection information > > > Establishing multiplexed-mode data connection > > > Running > > > TreeList failed: Network write failure: Connection closed > > > > > > this has been persistent for some hours > > > > This is a network problem. The connection was closed (e.g. the cleaning > > personel pulled the plug of the NIC by accident...). > > > > This problem can be on your end of the connection, on the cvsup10 side, > > or somewhere in between. > > I get the same error with that server, it is annoying. [cc to hubs@] For what it's worth I saw the same with cvsup.uk.freebsd.org (I'm using cvsup2.uk now). Maybe it's a wider spread problem, or maybe it's just load with 6.0 being released ... Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 20:52:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F31C116A41F; Tue, 8 Nov 2005 20:52:51 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2117B43D45; Tue, 8 Nov 2005 20:52:49 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028576.msg; Wed, 09 Nov 2005 02:52:40 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 126749, updated: 7.11.2005] To: freebsd-current@freebsd.org References: <20051027022313.R675@kushnir1.kiev.ua> <200511030059.05946.max@love2party.net> <200511031500.00839.jhb@freebsd.org> From: Victor Snezhko Date: Wed, 09 Nov 2005 02:52:39 +0600 In-Reply-To: (Victor Snezhko's message of "Fri, 04 Nov 2005 17:01:46 +0600") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Processed: indor.net.tomline.ru, Wed, 09 Nov 2005 02:52:40 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: Max Laier Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 20:52:52 -0000 --=-=-= Victor Snezhko writes: >> Tomorrow I'll try to trace all callout-related operations in nd6 >> and/or the whole netinet6. > > Hmmm... trace shows that the callout_stop/callout_drain call > always receives a pointer that has not been initialized via > callout_init, at least not in /usr/src/sys/netinet6/* Sorry, I lied here. Details below. > I'll debug this further and report the results. Hmm, debugging was not so fast... So, here is what I have for the moment: 1) I was dead wrong about stop called on a pointer that was not initialized(there was a typo in one of my printf's). Call trace shows the following: At first, nd6_rtrequest(RTM_ADD) is called, it calls callout_init on the timer and then callout_stop (through nd6_llinfo_settimer). Then nd6_rtrequest(RTM_DELETE) is called, and it calls callout_stop without callout_init. This seemed to be one of the possible cause of the problem, but when I commented out the last call to nd6_llinfo_settimer(ln, -1), nothing changed. 2) I tried to trace where corruption occurs. In order to do this I inserted slow checks into all the code in kern_timeout.c that could modify the callwheel. No success - first 0xdeadc0de's were detected by softclock(), not by any other call. Here is the corresponding patch: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=kern_timeout.diff --- kern_timeout.c.orig Mon Nov 7 17:26:56 2005 +++ kern_timeout.c Wed Nov 9 02:14:50 2005 @@ -110,6 +110,47 @@ static struct cv callout_wait; static int wakeup_done_ctr; +void callout_check_callwheel(void); + +/* + * callout_check_callwheel() - check all the callwheel for deadc0de'd entries + * + * This code cycles through the callwheel and if it finds + * broken callout, it panics. + * + * callout_lock must be acquired before calling this function + * + */ +void +callout_check_callwheel(void) +{ + struct callout *c, *c2; + struct callout_tailq *bucket; + int i; + static int in_panic=0; + + if (in_panic) return; + + for (i = 0; i < callwheelsize; ++i) { + bucket = &callwheel[i]; + c = TAILQ_FIRST(bucket); + if ((int)c == 0xdeadc0de) { + in_panic = 1; + panic("deadc0de found at the beginning of bucket"); + break; + } + while (c) { + c2 = TAILQ_NEXT(c, c_links.tqe); + if ((int)c2 == 0xdeadc0de) { + in_panic = 1; + panic("c->TAILQ_NEXT = 0xdeadc0de"); + break; + } + c = c2; + } + } +} + /* * kern_timeout_callwheel_alloc() - kernel low level callwheel initialization * @@ -206,6 +247,9 @@ depth = 0; steps = 0; mtx_lock_spin(&callout_lock); + + callout_check_callwheel(); + while (softticks != ticks) { softticks++; /* @@ -335,6 +379,9 @@ avg_mtxcalls += (mtxcalls * 1000 - avg_mtxcalls) >> 8; avg_gcalls += (gcalls * 1000 - avg_gcalls) >> 8; nextsoftcheck = NULL; + + callout_check_callwheel(); + mtx_unlock_spin(&callout_lock); } @@ -365,16 +412,23 @@ mtx_lock_spin(&callout_lock); + callout_check_callwheel(); + /* Fill in the next free callout structure. */ new = SLIST_FIRST(&callfree); if (new == NULL) /* XXX Attempt to malloc first */ panic("timeout table full"); SLIST_REMOVE_HEAD(&callfree, c_links.sle); - + + callout_check_callwheel(); + callout_reset(new, to_ticks, ftn, arg); handle.callout = new; + + callout_check_callwheel(); + mtx_unlock_spin(&callout_lock); return (handle); } @@ -395,8 +449,14 @@ return; mtx_lock_spin(&callout_lock); + + callout_check_callwheel(); + if (handle.callout->c_func == ftn && handle.callout->c_arg == arg) callout_stop(handle.callout); + + callout_check_callwheel(); + mtx_unlock_spin(&callout_lock); } @@ -437,6 +497,9 @@ #endif mtx_lock_spin(&callout_lock); + + callout_check_callwheel(); + if (c == curr_callout) { /* * We're being asked to reschedule a callout which is @@ -463,6 +526,8 @@ cancelled = 1; + callout_check_callwheel(); + /* * Part of the normal "stop a pending callout" process * is to clear the CALLOUT_ACTIVE and CALLOUT_PENDING @@ -481,14 +546,20 @@ if (to_ticks <= 0) to_ticks = 1; + callout_check_callwheel(); + c->c_arg = arg; c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); c->c_func = ftn; c->c_time = ticks + to_ticks; + TAILQ_INSERT_TAIL(&callwheel[c->c_time & callwheelmask], c, c_links.tqe); - mtx_unlock_spin(&callout_lock); + callout_check_callwheel(); + + mtx_unlock_spin(&callout_lock); + return (cancelled); } @@ -511,6 +582,9 @@ } mtx_lock_spin(&callout_lock); + + callout_check_callwheel(); + /* * Don't attempt to delete a callout that's not on the queue. */ @@ -547,15 +621,25 @@ } c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING); + callout_check_callwheel(); + if (nextsoftcheck == c) { nextsoftcheck = TAILQ_NEXT(c, c_links.tqe); } + + callout_check_callwheel(); + TAILQ_REMOVE(&callwheel[c->c_time & callwheelmask], c, c_links.tqe); + callout_check_callwheel(); + if (c->c_flags & CALLOUT_LOCAL_ALLOC) { c->c_func = NULL; SLIST_INSERT_HEAD(&callfree, c, c_links.sle); } + + callout_check_callwheel(); + mtx_unlock_spin(&callout_lock); return (1); } @@ -641,6 +725,9 @@ /* don't collide with softclock() */ mtx_lock_spin(&callout_lock); + + callout_check_callwheel(); + for (p = calltodo.c_next; p != NULL; p = p->c_next) { p->c_time -= delta_ticks; @@ -651,6 +738,9 @@ /* take back the ticks the timer didn't use (p->c_time <= 0) */ delta_ticks = -p->c_time; } + + callout_check_callwheel(); + mtx_unlock_spin(&callout_lock); return; --=-=-= pointer comparisons are probably not 64bit-clean, correct me please if those pointer->int casts are bad. If the backtrace is needed I can provide it, just ask. My check triggers panic when called from a softclock(). 3) Recently, thanks to Mark Tinguely, I have found out that I could do additional checks in trash_dtor() in uma_dbg.c No results again. I inserted the following check: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=uma_dbg.diff --- uma_dbg.c.orig Mon Nov 7 23:05:09 2005 +++ uma_dbg.c Tue Nov 8 17:37:24 2005 @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include @@ -86,8 +88,33 @@ { int cnt; u_int32_t *p; + struct callout *c; + struct callout_tailq *bucket; + int i; cnt = size / sizeof(uma_junk); + + mtx_lock_spin(&callout_lock); + + for (i = 0; i < callwheelsize; ++i) { + bucket = &callwheel[i]; + for (c = TAILQ_FIRST(bucket); c != NULL; + c = TAILQ_NEXT(c, c_links.tqe)) { + int c2 = (int)c; + int mem2 = (int)mem; + if ((u_int32_t)c == uma_junk) { + kdb_enter("trash_dtor: uma_junk found in a "\ + "callwheel element"); + break; + } + if (c2 >= mem2 && c2 < mem2 + size) { + kdb_enter("trash_dtor: found invalid "\ + "callwhel element"); + } + } + } + + mtx_unlock_spin(&callout_lock); for (p = mem; cnt > 0; cnt--, p++) *p = uma_junk; --=-=-= (Again not quite 64bit-ready, the same nasty pointer casts) Here is the backtrace: --=-=-= Content-Disposition: inline; filename=bt2.txt /var/crash # kgdb /usr/obj/usr/src/sys/VVS/kernel vmcore.24 [... skipped ...] Unread portion of the kernel message buffer: KDB: enter: trash_dtor: uma_junk found in a callwheel element panic: from debugger cpuid = 0 Uptime: 4m2s Dumping 63 MB (3 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 62MB (15856 pages) 46 30 14 ... ok chunk 2: 1MB (256 pages) #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0660824 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0660b39 in panic (fmt=0xc0856fa0 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc046cee1 in db_panic (addr=-1066954485, have_addr=0, count=-1, modif=0xc60ac934 "") at /usr/src/sys/ddb/db_command.c:434 #4 0xc046ce78 in db_command (last_cmdp=0xc0947a84, cmd_table=0x0, aux_cmd_tablep=0xc08bda78, aux_cmd_tablep_end=0xc08bda94) at /usr/src/sys/ddb/db_command.c:403 #5 0xc046cf40 in db_command_loop () at /usr/src/sys/ddb/db_command.c:454 #6 0xc046eb59 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc06793a4 in kdb_trap (type=3, code=0, tf=0xc60acacc) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc0821630 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1053265664, tf_esi = -1053265920, tf_ebp = -972371188, tf_isp = -972371208, tf_ebx = -559038242, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 62, tf_trapno = 3, tf_err = 0, tf_eip = -1066954485, tf_cs = 32, tf_eflags = 646, tf_esp = -972371156, tf_ss = -1065665882}) at /usr/src/sys/i386/i386/trap.c:610 #9 0xc080ecba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc067910b in kdb_enter (msg=0x3e
) ---Type to continue, or q to quit--- at cpufunc.h:60 #11 0xc07b3aa6 in trash_dtor (mem=0xc1387000, size=256, arg=0x0) at /usr/src/sys/vm/uma_dbg.c:104 #12 0xc0657dd8 in mb_dtor_mbuf (mem=0xc1387000, size=256, arg=0x0) at /usr/src/sys/kern/kern_mbuf.c:245 #13 0xc07b23e4 in uma_zfree_arg (zone=0xc1042960, item=0xc1387000, udata=0x0) at /usr/src/sys/vm/uma_core.c:2270 #14 0xc069b9ba in soreceive (so=0xc143d9bc, psa=0xc60acbe8, uio=0xc60acbf4, mp0=0x0, controlp=0x0, flagsp=0xc60acc74) at uma.h:303 #15 0xc06a08c7 in kern_recvit (td=0xc12f3320, s=5, mp=0xc60acc5c, namelenp=0xbfbfdacc, segflg=62) at /usr/src/sys/kern/uipc_syscalls.c:986 #16 0xc06a0af6 in recvit (td=0xc12f3320, s=5, mp=0xc60acc5c, namelenp=0xbfbfdacc) at /usr/src/sys/kern/uipc_syscalls.c:1094 #17 0xc06a0b64 in recvfrom (td=0xc12f3320, uap=0xc60acd04) at /usr/src/sys/kern/uipc_syscalls.c:1131 #18 0xc0821e96 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134570084, tf_esi = 134570080, tf_ebp = -1077940616, tf_isp = -972370588, tf_ebx = 134546020, tf_edx = -1077940864, tf_ecx = 5, tf_eax = 29, tf_trapno = 32, tf_err = 2, tf_eip = 672166495, tf_cs = 51, tf_eflags = 66198, tf_esp = -1077945812, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1001 ---Type to continue, or q to quit--- #19 0xc080ed0f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 11 #11 0xc07b3aa6 in trash_dtor (mem=0xc1387000, size=256, arg=0x0) at /usr/src/sys/vm/uma_dbg.c:104 104 kdb_enter("trash_dtor: uma_junk found in a "\ (kgdb) list 99 for (c = TAILQ_FIRST(bucket); c != NULL; 100 c = TAILQ_NEXT(c, c_links.tqe)) { 101 int c2 = (int)c; 102 int mem2 = (int)mem; 103 if ((u_int32_t)c == uma_junk) { 104 kdb_enter("trash_dtor: uma_junk found in a "\ 105 "callwheel element"); 106 break; 107 } 108 if (c2 >= mem2 && c2 < mem2 + size) { (kgdb) up 1 #12 0xc0657dd8 in mb_dtor_mbuf (mem=0xc1387000, size=256, arg=0x0) at /usr/src/sys/kern/kern_mbuf.c:245 245 trash_dtor(mem, size, arg); (kgdb) list 240 241 m = (struct mbuf *)mem; 242 if ((m->m_flags & M_PKTHDR) != 0) 243 m_tag_delete_chain(m, NULL); 244 #ifdef INVARIANTS 245 trash_dtor(mem, size, arg); 246 #endif 247 } 248 249 /* XXX Only because of stats */ (kgdb) up 1 #13 0xc07b23e4 in uma_zfree_arg (zone=0xc1042960, item=0xc1387000, udata=0x0) at /usr/src/sys/vm/uma_core.c:2270 2270 zone->uz_dtor(item, keg->uk_size, udata); (kgdb) list 2265 #endif 2266 CTR2(KTR_UMA, "uma_zfree_arg thread %x zone %s", curthread, 2267 zone->uz_name); 2268 2269 if (zone->uz_dtor) 2270 zone->uz_dtor(item, keg->uk_size, udata); 2271 #ifdef INVARIANTS 2272 ZONE_LOCK(zone); 2273 if (keg->uk_flags & UMA_ZONE_MALLOC) 2274 uma_dbg_free(zone, udata, item); (kgdb) up 1 #14 0xc069b9ba in soreceive (so=0xc143d9bc, psa=0xc60acbe8, uio=0xc60acbf4, mp0=0x0, controlp=0x0, flagsp=0xc60acc74) at uma.h:303 303 uma_zfree_arg(zone, item, NULL); (kgdb) list 298 static __inline void uma_zfree(uma_zone_t zone, void *item); 299 300 static __inline void 301 uma_zfree(uma_zone_t zone, void *item) 302 { 303 uma_zfree_arg(zone, item, NULL); 304 } 305 306 /* 307 * XXX The rest of the prototypes in this header are h0h0 magic for the VM. (kgdb) up 1 #15 0xc06a08c7 in kern_recvit (td=0xc12f3320, s=5, mp=0xc60acc5c, namelenp=0xbfbfdacc, segflg=62) at /usr/src/sys/kern/uipc_syscalls.c:986 986 error = so->so_proto->pr_usrreqs->pru_soreceive(so, &fromsa, &auio, (kgdb) list 981 #ifdef KTRACE 982 if (KTRPOINT(td, KTR_GENIO)) 983 ktruio = cloneuio(&auio); 984 #endif 985 len = auio.uio_resid; 986 error = so->so_proto->pr_usrreqs->pru_soreceive(so, &fromsa, &auio, 987 (struct mbuf **)0, mp->msg_control ? &control : (struct mbuf **)0, 988 &mp->msg_flags); 989 if (error) { 990 if (auio.uio_resid != (int)len && (error == ERESTART || (kgdb) print *(so->so_proto->pr_usrreqs) $5 = {__Break_the_struct_layout_for_now = 0, pru_abort = 0xc06a24ec , pru_accept = 0xc06a2600 , pru_attach = 0xc06a26b4 , pru_bind = 0xc06a26d0 , pru_connect = 0xc06a2740 , pru_connect2 = 0xc06a27c8 , pru_control = 0xc069f300 , pru_detach = 0xc06a2838 , pru_disconnect = 0xc06a28a0 , pru_listen = 0xc06a2908 , pru_peeraddr = 0xc06a2980 , pru_rcvd = 0xc06a2a34 , pru_rcvoob = 0xc069f348 , pru_send = 0xc06a2bc4 , pru_sense = 0xc06a3024 , pru_shutdown = 0xc06a30f0 , pru_sockaddr = 0xc06a3168 , pru_sosend = 0xc069ad84 , pru_soreceive = 0xc069b5b0 , pru_sopoll = 0xc069d090 , pru_sosetlabel = 0xc069f3b8 } (kgdb) up 1 #16 0xc06a0af6 in recvit (td=0xc12f3320, s=5, mp=0xc60acc5c, namelenp=0xbfbfdacc) at /usr/src/sys/kern/uipc_syscalls.c:1094 1094 return (kern_recvit(td, s, mp, namelenp, UIO_USERSPACE)); (kgdb) list 1089 int s; 1090 struct msghdr *mp; 1091 void *namelenp; 1092 { 1093 1094 return (kern_recvit(td, s, mp, namelenp, UIO_USERSPACE)); 1095 } 1096 1097 /* 1098 * MPSAFE --=-=-= The thing I want to note is that callwheel corruptions after applying this patch stop to be reproducible. They may occur, may not. 4) I inserted a kdb_enter() call in the beginning of nd6_llinfo_settimer(). Then tried to step some functions up the stack. Pressed "n" a couple of times, then exit via "c". Panic didn't occur! (It would certainly occur if I exited the kdb immediately after kdb_enter). Don't know what to think about the last. Improper locking? Freeing a callwheel entry and then it's slow removal? Strange... P.S.: Perharps I should file a PR about all this as the problem turned out to be not so easy. To what degree should I include the details above? -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 21:34:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E251B16A420 for ; Tue, 8 Nov 2005 21:34:03 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id C545043D46 for ; Tue, 8 Nov 2005 21:33:59 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so9680nzd for ; Tue, 08 Nov 2005 13:33:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=orzUKDAFboD2WUQgEsk9fLUM7/tV9mDzQHN8y58ranWMT1WqtJiu8VozdvIgkwiCek6Rw8G4D2THkGn4snzEy43F6cA8y7YRWp6C2IrzyD2cS9WXu3eNT7ieb6C64m7f6aRWo6d1EgQrOdtuvheGfi1UX6ywBxldY3/8aQ893og= Received: by 10.36.221.49 with SMTP id t49mr1880297nzg; Tue, 08 Nov 2005 13:06:11 -0800 (PST) Received: by 10.36.135.15 with HTTP; Tue, 8 Nov 2005 13:06:11 -0800 (PST) Message-ID: <621b657f0511081306r53744034rc32275a0f214f2a1@mail.gmail.com> Date: Tue, 8 Nov 2005 19:06:11 -0200 From: Felipe openglx Sender: felipegrazziotin@gmail.com To: Nate Eldredge In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17264.64843.738921.535657@roam.psg.com> <20051108204256.385b11fc@Magellan.Leidinger.net> Cc: Randy Bush , Alexander Leidinger , FreeBSD Current Subject: Re: cvsup10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 21:34:04 -0000 On 11/8/05, Nate Eldredge wrote: > On Tue, 8 Nov 2005, Alexander Leidinger wrote: > > > On Tue, 8 Nov 2005 09:32:27 -1000 > > Randy Bush wrote: > > > >> can't find an appropriate list, so i'll whine here. > >> > >> Connecting to cvsup10.freebsd.org > >> Connected to cvsup10.freebsd.org > >> Server software version: SNAP_16_1h > >> Negotiating file attribute support > >> Exchanging collection information > >> Establishing multiplexed-mode data connection > >> Running > >> TreeList failed: Network write failure: Connection closed > >> > >> this has been persistent for some hours > > > > This is a network problem. The connection was closed (e.g. the cleaning > > personel pulled the plug of the NIC by accident...). > > > > This problem can be on your end of the connection, on the cvsup10 side, > > or somewhere in between. > > Maybe it's due to heavy server load? Since 6.0 was just released a coupl= e > days ago, there are probably a lot of people cvsup-ing it. You could try > a different mirror or wait another couple of days. > I bet it is something related to heavy server load, as cvsup.br showed me problems like those presented here. I just switched to cvsup2.br and it is working perfectly. Try a few other mirrors :) From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 21:36:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7451E16A420 for ; Tue, 8 Nov 2005 21:36:11 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0899F43D45 for ; Tue, 8 Nov 2005 21:36:10 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp6-g19.free.fr (Postfix) with ESMTP id 19A71969E for ; Tue, 8 Nov 2005 22:36:10 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA8LZnjd023905; Tue, 8 Nov 2005 22:35:53 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Tue, 8 Nov 2005 22:35:41 +0100 User-Agent: KMail/1.8.3 References: <20051107094655.GA76489@cirb503493.alcatel.com.au> <200511081913.15042.thierry@herbelot.com> <20051108.121858.51703736.imp@bsdimp.com> In-Reply-To: <20051108.121858.51703736.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511082235.42725.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 21:36:11 -0000 Le Tuesday 8 November 2005 20:18, M. Warner Losh a écrit : > Does this solve the problem? > > Warner > [SNIP the patch] so far, so good : %w 22:35 up 1:51, 3 users, load averages: 1,78 1,99 2,05 (the machine is rebuilding the world and some ports) We'll see tomorrow if the machine is still fine ;-) TfH From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 22:10:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCCD916A41F for ; Tue, 8 Nov 2005 22:10:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C05143D46 for ; Tue, 8 Nov 2005 22:10:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA8M8G7Y027639; Tue, 8 Nov 2005 15:08:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Nov 2005 15:08:47 -0700 (MST) Message-Id: <20051108.150847.27281507.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511082235.42725.thierry@herbelot.com> References: <200511081913.15042.thierry@herbelot.com> <20051108.121858.51703736.imp@bsdimp.com> <200511082235.42725.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 08 Nov 2005 15:08:17 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 22:10:01 -0000 In message: <200511082235.42725.thierry@herbelot.com> Thierry Herbelot writes: : Le Tuesday 8 November 2005 20:18, M. Warner Losh a =E9crit : : > Does this solve the problem? : > : > Warner : > : [SNIP the patch] : = : so far, so good : : %w : 22:35 up 1:51, 3 users, load averages: 1,78 1,99 2,05 : = : (the machine is rebuilding the world and some ports) : = : We'll see tomorrow if the machine is still fine ;-) Did you get this crash spontaneously, or only when you suspended? Warner From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:13:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C68816A41F for ; Tue, 8 Nov 2005 23:13:39 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28D4943D45 for ; Tue, 8 Nov 2005 23:13:39 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jA8NDbdL005917; Tue, 8 Nov 2005 17:13:37 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jA8NDbft005916; Tue, 8 Nov 2005 17:13:37 -0600 (CST) (envelope-from tinguely) Date: Tue, 8 Nov 2005 17:13:37 -0600 (CST) From: Mark Tinguely Message-Id: <200511082313.jA8NDbft005916@casselton.net> To: freebsd-current@freebsd.org, snezhko@indorsoft.ru In-Reply-To: X-Spam-Status: No, score=0.6 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net Cc: max@love2party.net Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 23:13:39 -0000 Okay, I am alittle dense in reading the soreceive() debugger line, basically the debugger trace must refer to an expansion of the m_free() inline definition in soreceive(). Either a callout is not being removed when the memory is freed and that memory is recycled to an MBUF OR someone is incorrectly chaining a memory location into an MBUF. before too much work is done (below), could you print out the callout that is being freed but active and the memory around it (before it is overwritten by "deadc0de"). It may tell us which callout that it is or was. You should be able to do that with your existing kernel. If we cannot glean who the callout is/was, then more tests can be added to determine if the UMA is allocating memory chained to the callout or if the MBUF chain is corrupted. --Mark Tinguely From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:29:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5457C16A420 for ; Tue, 8 Nov 2005 23:29:09 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9485343D45 for ; Tue, 8 Nov 2005 23:29:06 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 05C9439834 for ; Wed, 9 Nov 2005 00:29:12 +0100 (CET) Date: Tue, 8 Nov 2005 23:28:55 +0000 From: Marcin Jessa To: FreeBSD-Current Message-Id: <20051108232855.2d1b7df5.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.3 (GTK+ 2.8.6; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 23:29:09 -0000 Hi guys. I just came across an article of Mr. Greg Kroah-Hartman in his blog http://www.kroah.com/log/2005/11/03/ about generic kernel API which could make it possible for hardware vendors to supply us with their own drivers. To be honest I disagree with Greg and consider this a good idea. Especially if we had a system which could isolate each device driver running as a separate user-mode process so it would not bring down the entire OS in case the driver was buggy. An API like that would both boost up FreeBSD's popularity and make it possible to use a way larger variety of hardware. I mean, lets not fool ourselves, the majority of hardware vendors is not interested in revealing of their secrets publishing freely avaliable documentation of their products. We could have a new choice to use (or not) binary drivers the same way the popular commercial O.Ss do. What do you guys think? What is the view of the FreeBSD community on this metter? Could this be concerned as a good idea ? Cheers, Marcin Jessa. From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 23:34:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06C0316A41F for ; Tue, 8 Nov 2005 23:34:08 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8A6343D46 for ; Tue, 8 Nov 2005 23:34:07 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 08 Nov 2005 15:34:07 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jA8NY69A073543; Tue, 8 Nov 2005 15:34:06 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jA8NY5u6073542; Tue, 8 Nov 2005 15:34:05 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200511082334.jA8NY5u6073542@ambrisko.com> In-Reply-To: To: "Lynn A. Roth" Date: Tue, 8 Nov 2005 15:34:05 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Problems Installing to PowerEdge 850 with SATA Drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 23:34:08 -0000 Lynn A. Roth writes: | Lynn A. Roth wrote: | > Doug Ambrisko wrote: | > | >> Doug Ambrisko writes: | >> | Doug Ambrisko writes: | >> | | Lynn A. Roth writes: | >> | | | I have two new Dell Poweredge 850 machines. They have an Intel | >> ICH7 | | | chipset. When I boot FreeBSD 6 RC1, the controller is | >> identified, but | | | any drives connected to the SATA ports are not | >> detected. The drive that | | | is included with the system is a | >> Seagate 7200.7 drive. I also tried a | | | Maxtor. | >> | | | | I can confirm the problem on the PE850. I have it working | >> with my | >> | | latest 4.X SATA patches (which I haven't published yet). I might | >> | | be able to look into this. | >> | | | >> Here's a hack to make it work on PE850 with -current: | >> | > | >> | >> This works for me on my PE850. It shouldn't break other stuff etc. | >> I assume the ICH6 will need the same type of change. | > | > Thanks for this patch. | > Scott from pfSense integrated this into his kernel and it worked great | > for me. | > | > Thanks again. | | Can this be committed sometime to current? I doubt it. Hopefully Soren will add support in some way. Atleast this is a proof of concept of the problem that needs to be implemented. Feel free to follow up with Soren (sos@freebsd.org). Doug A. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 00:42:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81A9516A41F for ; Wed, 9 Nov 2005 00:42:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A09C043D46 for ; Wed, 9 Nov 2005 00:42:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA90g07t087970; Tue, 8 Nov 2005 17:42:03 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <437145DF.2040508@samsco.org> Date: Tue, 08 Nov 2005 17:42:07 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20051108232855.2d1b7df5.lists@yazzy.org> In-Reply-To: <20051108232855.2d1b7df5.lists@yazzy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: FreeBSD-Current Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 00:42:06 -0000 Marcin Jessa wrote: > Hi guys. > > I just came across an article of Mr. Greg Kroah-Hartman in his blog > http://www.kroah.com/log/2005/11/03/ > about generic kernel API which could make it possible for hardware > vendors to supply us with their own drivers. > To be honest I disagree with Greg and consider this a good idea. > Especially if we had a system which could isolate each device driver > running as a separate user-mode process so it would not bring down the > entire OS in case the driver was buggy. > An API like that would both boost up FreeBSD's popularity and make it > possible to use a way larger variety of hardware. > I mean, lets not fool ourselves, the majority of hardware vendors is > not interested in revealing of their secrets publishing freely > avaliable documentation of their products. > We could have a new choice to use (or not) binary drivers the > same way the popular commercial O.Ss do. > What do you guys think? What is the view of the > FreeBSD community on this metter? > Could this be concerned as a good idea ? > > > Cheers, > Marcin Jessa. Please don't take this the wrong way, but google for 'Universal Driver Interface'. Yes, this topic comes up every few years. It sounds like a good idea, but every OS has unique and incompatible ways of doing things. Sure, it's easy to map malloc in FreeBSD to kmalloc in Linux, but how do you map ithreads in FreeBSD and Solaris to Linux? How do you map busdma in FreeBSD to busdma in NetBSD, let alone Linux where there is little concept of a DMA abstraction? How do you map newbus in FreeBSD to, um, nothing in Linux? How do you map VFS on FreeBSD to VFS on Linux or Solaris? All of these things make such a unification effort impossible to do without watering it down to where it is either functionally useless or too slow and abstract to matter. Ironically, Project Evil has bridged the gap the best, but it limits its scope to the Windows NDIS API. It might be possible to expand it to cover StorPort also, but forget about much more than that. Scott From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:36:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA4C16A41F for ; Wed, 9 Nov 2005 01:36:22 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 675DD43D48 for ; Wed, 9 Nov 2005 01:36:22 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 87318 invoked from network); 9 Nov 2005 01:36:21 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 9 Nov 2005 01:36:21 -0000 Message-ID: <43715294.3080604@redstarling.com> Date: Wed, 09 Nov 2005 09:36:20 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vinod Kashyap References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> In-Reply-To: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 01:36:22 -0000 Vinod Kashyap wrote: >>-----Original Message----- >>From: owner-freebsd-current@freebsd.org >>[mailto:owner-freebsd-current@freebsd.org] On Behalf Of ke.han >>Sent: Tuesday, November 08, 2005 5:24 AM >>To: freebsd-current@freebsd.org >>Subject: 3ware 9550sx driver for freeBSD 6 amd64 ?? >> >>Does anyone have the latest compiled driver, twa.ko, for the >>9550SX on freeBSD 6 amd64? >>I have a problem where I cannot compile the driver without >>installing freeBSD 6 to my new server and cannot install to >>the server without the compiled driver. >>The source can be downloaded from a link at the end of this page: >>http://www.3ware.com/KB/article.aspx?id=14546 >> > > > The driver integrated into FreeBSD 6.0 does not know about SX > controllers. > So, you cannot install FreeBSD 6.0 on SX. For installation purposes, > there > are plans to provide an SX driver for 6.0 (and 5.4) which can be loaded > from > a floppy. I am aware of all this. This knowledge base article I reference (here it is again: http://www.3ware.com/KB/article.aspx?id=14546 has the source and instructions for the new driver. All that is needed is for someone to compile it!!! I cannot compile this for 64 bit since I don't have a working machine with EM64T until after I have a compiled driver. Is there anyone out there with an EM64T box that can download the source and instructions and compile the driver?? thanks, Jon > -------------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 02:31:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B69F16A41F for ; Wed, 9 Nov 2005 02:31:37 +0000 (GMT) (envelope-from michaelmeltzer@yahoo.com) Received: from web30110.mail.mud.yahoo.com (web30110.mail.mud.yahoo.com [68.142.200.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 6F75A43D46 for ; Wed, 9 Nov 2005 02:31:36 +0000 (GMT) (envelope-from michaelmeltzer@yahoo.com) Received: (qmail 84899 invoked by uid 60001); 9 Nov 2005 02:31:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lM0/4IwlqHO/wRwG548JfuMmUhrxS/AN9h/HoiTI9DzSviJbfjT+XQWwgkydrG6KRvrFZTjwbJR/CJyV3nUBuszN5hEC9jI812rBHZS+0eIDRkK7Uu624E1lyiAi/kvuTraUPHDt1WkMz136o9WCUUarSD+HUMxAnTGx4kN2ie0= ; Message-ID: <20051109023135.84897.qmail@web30110.mail.mud.yahoo.com> Received: from [67.86.102.200] by web30110.mail.mud.yahoo.com via HTTP; Tue, 08 Nov 2005 18:31:35 PST Date: Tue, 8 Nov 2005 18:31:35 -0800 (PST) From: michael meltzer To: Vinod Kashyap , "ke.han" , freebsd-current@freebsd.org In-Reply-To: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: RE: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjm@michaelmeltzer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 02:31:37 -0000 Why make it hard on people??? Just add it to GENERIC and maybe turn on automatic firmware download also? Their is nothing so flustering than not being able to load due to raid card. Step one for some people is try a different OS. and they might not know enough to even check the support page -mjm BTW a quick work around is take one on the drives off the raid(or a spare) and use the motherboard connection, load the OS, build the driver, boot the raid and copy the OS over to it and boot into it, the disk goes back onto the raid as HOT spare. PITA I know. PSS. bad user expreance people - Vinod.... --- Vinod Kashyap wrote: > > -----Original Message----- > > From: owner-freebsd-current@freebsd.org > > [mailto:owner-freebsd-current@freebsd.org] On > Behalf Of ke.han > > Sent: Tuesday, November 08, 2005 5:24 AM > > To: freebsd-current@freebsd.org > > Subject: 3ware 9550sx driver for freeBSD 6 amd64 > ?? > > > > Does anyone have the latest compiled driver, > twa.ko, for the > > 9550SX on freeBSD 6 amd64? > > I have a problem where I cannot compile the driver > without > > installing freeBSD 6 to my new server and cannot > install to > > the server without the compiled driver. > > The source can be downloaded from a link at the > end of this page: > > http://www.3ware.com/KB/article.aspx?id=14546 > > > > The driver integrated into FreeBSD 6.0 does not know > about SX > controllers. > So, you cannot install FreeBSD 6.0 on SX. For > installation purposes, > there > are plans to provide an SX driver for 6.0 (and 5.4) > which can be loaded > from > a floppy. > -------------------------------------------------------- > > CONFIDENTIALITY NOTICE: This e-mail message, > including any attachments, is for the sole use of > the intended recipient(s) and contains information > that is confidential and proprietary to Applied > Micro Circuits Corporation or its subsidiaries. It > is to be used solely for the purpose of furthering > the parties' business relationship. All unauthorized > review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, > please contact the sender by reply e-mail and > destroy all copies of the original message. > _______________________________________________ > 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" > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 03:23:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46B8C16A41F for ; Wed, 9 Nov 2005 03:23:15 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from sdcexchange01.amcc.com (gatekeeper-out.amcc.com [198.137.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84B0743D45 for ; Wed, 9 Nov 2005 03:23:14 +0000 (GMT) (envelope-from vkashyap@amcc.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2005 19:23:09 -0800 Message-ID: <2B3B2AA816369A4E87D7BE63EC9D2F26F012FE@SDCEXCHANGE01.ad.amcc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3ware 9550sx driver for freeBSD 6 amd64 ?? Thread-Index: AcXk1XHBI+NjsFm+T4mrEF3jO9RdlAABIG/w From: "Vinod Kashyap" To: , "ke.han" , Cc: Subject: RE: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 03:23:15 -0000 =20 > -----Original Message----- > From: michael meltzer [mailto:michaelmeltzer@yahoo.com]=20 > Sent: Tuesday, November 08, 2005 6:32 PM > To: Vinod Kashyap; ke.han; freebsd-current@freebsd.org > Subject: RE: 3ware 9550sx driver for freeBSD 6 amd64 ?? >=20 > Why make it hard on people??? Just add it to GENERIC and=20 > maybe turn on automatic firmware download also? It's the same driver (twa) for SX, and it's already in GENERIC. Automatic firmware download is disabled because it will make the driver too big to fit into installation floppies. > Their is nothing so flustering than not being able to load=20 > due to raid card. Step one for some people is try a different=20 > OS. and they might not know enough to even check the support page -mjm >=20 Whenever a new controller series is released, and it's not supported by the driver in the kernel, there is going to be this problem. > BTW a quick work around is take one on the drives off the=20 > raid(or a spare) and use the motherboard connection, load the=20 > OS, build the driver, boot the raid and copy the OS over to=20 > it and boot into it, the disk goes back onto the raid as HOT=20 > spare. PITA I know. >=20 > PSS. bad user expreance people - Vinod.... >=20 > --- Vinod Kashyap wrote: >=20 > > > -----Original Message----- > > > From: owner-freebsd-current@freebsd.org=20 > > > [mailto:owner-freebsd-current@freebsd.org] On > > Behalf Of ke.han > > > Sent: Tuesday, November 08, 2005 5:24 AM > > > To: freebsd-current@freebsd.org > > > Subject: 3ware 9550sx driver for freeBSD 6 amd64 > > ?? > > >=20 > > > Does anyone have the latest compiled driver, > > twa.ko, for the > > > 9550SX on freeBSD 6 amd64? > > > I have a problem where I cannot compile the driver > > without > > > installing freeBSD 6 to my new server and cannot > > install to > > > the server without the compiled driver. > > > The source can be downloaded from a link at the > > end of this page: > > > http://www.3ware.com/KB/article.aspx?id=3D14546 > > >=20 > >=20 > > The driver integrated into FreeBSD 6.0 does not know about SX=20 > > controllers. > > So, you cannot install FreeBSD 6.0 on SX. For installation=20 > purposes,=20 > > there are plans to provide an SX driver for 6.0 (and 5.4)=20 > which can be=20 > > loaded from a floppy. > > > -------------------------------------------------------- > >=20 > > CONFIDENTIALITY NOTICE: This e-mail message, including any=20 > > attachments, is for the sole use of the intended recipient(s) and=20 > > contains information that is confidential and proprietary=20 > to Applied=20 > > Micro Circuits Corporation or its subsidiaries. It is to be used=20 > > solely for the purpose of furthering the parties' business=20 > > relationship. All unauthorized review, use, disclosure or=20 > distribution=20 > > is prohibited. If you are not the intended recipient,=20 > please contact=20 > > the sender by reply e-mail and destroy all copies of the original=20 > > message. > > _______________________________________________ > > 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 >=20 >=20 >=20 > =09 > =09 > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com >=20 From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 03:43:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9413F16A41F for ; Wed, 9 Nov 2005 03:43:58 +0000 (GMT) (envelope-from michaelmeltzer@yahoo.com) Received: from web30102.mail.mud.yahoo.com (web30102.mail.mud.yahoo.com [68.142.200.75]) by mx1.FreeBSD.org (Postfix) with SMTP id F40AF43D5D for ; Wed, 9 Nov 2005 03:43:56 +0000 (GMT) (envelope-from michaelmeltzer@yahoo.com) Received: (qmail 60416 invoked by uid 60001); 9 Nov 2005 03:43:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zJgClnNwt0y/KEihsoMGYhuB95CYLDpPJc7nidBtVs+07oDcLHb4ODHSzDsYzyH4YFCcbDwosz0omjDrYjztX/pBW7xttaqTAces0aQ5Dtx/ClDaaDYS6eZvDx6tobuManHAE6GnLChEBi1S/FSVSDyVlTNW5lS2F5HOyyL7Ds4= ; Message-ID: <20051109034356.60414.qmail@web30102.mail.mud.yahoo.com> Received: from [67.86.102.200] by web30102.mail.mud.yahoo.com via HTTP; Tue, 08 Nov 2005 19:43:56 PST Date: Tue, 8 Nov 2005 19:43:56 -0800 (PST) From: michael meltzer To: Vinod Kashyap , mjm@michaelmeltzer.com, "ke.han" , freebsd-current@freebsd.org In-Reply-To: <2B3B2AA816369A4E87D7BE63EC9D2F26F012FE@SDCEXCHANGE01.ad.amcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: RE: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjm@michaelmeltzer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 03:43:58 -0000 > It's the same driver (twa) for SX, and it's already > in GENERIC. > Automatic firmware download is disabled because it > will make > the driver too big to fit into installation > floppies. > > My apologies, it was sounding like a new driver, also I was little quick remebering a few long nights I had. FWIW once the source is in the tree might me nice that the default build does load the driver. keep the card in sync with cvsup -mjm __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 03:44:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 739C816A41F for ; Wed, 9 Nov 2005 03:44:58 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp102.biz.mail.mud.yahoo.com (smtp102.biz.mail.mud.yahoo.com [68.142.200.237]) by mx1.FreeBSD.org (Postfix) with SMTP id F0D0443D45 for ; Wed, 9 Nov 2005 03:44:57 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 5358 invoked from network); 9 Nov 2005 03:44:57 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp102.biz.mail.mud.yahoo.com with SMTP; 9 Nov 2005 03:44:56 -0000 Message-ID: <437170B9.3020709@redstarling.com> Date: Wed, 09 Nov 2005 11:44:57 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Devon H. O'Dell" References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> <9ab217670511081836t7e21b0e3k@mail.gmail.com> In-Reply-To: <9ab217670511081836t7e21b0e3k@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 03:44:58 -0000 Devon H. O'Dell wrote: >>I am aware of all this. This knowledge base article I reference (here >>it is again: http://www.3ware.com/KB/article.aspx?id=14546 has the >>source and instructions for the new driver. All that is needed is for >>someone to compile it!!! I cannot compile this for 64 bit since I don't >>have a working machine with EM64T until after I have a compiled driver. >> >>Is there anyone out there with an EM64T box that can download the source >>and instructions and compile the driver?? >> >>thanks, Jon > > > You can't use a module since the twa driver is in 6.0-RELEASE and the > module won't load since it uses the same symbols. However, my > coworker, Seth Kingsley compiled it today for 6.0-RELEASE and just > gave me the CD, so if you can wait for a couple minutes, I'll put it > up on http://www.sitetronics.com/~dodell/kernel-9550sx > > --Devon > Thanks for the download...got it. why is your file 7m when the kernel module I compiled for i386 is only 57k? Also, are you saying that I must compile the driver into the kernel? This means I first have to be able to install to a single drive on the system first, right?? If this is the case, this gets me back to my other problem which is the 6.0-RELEASE installer won't find my single hard drive (either EIDE or SATA) which I have directly connected to the tyan i7520 mobo ;-( ...I have posted this problem as a seperate discussion in paralle with this one. thanks, ke han From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 04:21:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E728416A41F for ; Wed, 9 Nov 2005 04:21:40 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CBE943D45 for ; Wed, 9 Nov 2005 04:21:40 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by xproxy.gmail.com with SMTP id t10so122412wxc for ; Tue, 08 Nov 2005 20:21:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cv3MW0xbpsLBLF9F3Rjlze0PPk3tzZkMSItxzPqpIn8oVTN1+YelJYtamUA4ydOdKvOCtvsuxCXgdrY3G/3UALPhlH8lsPrm25jDp6KznxmWgvE+ZGzlTZvbhJ6BaD2uDi3QYAv4+yUw8CnVq/z8JmBLa9IG9pArdXHq3HAlNng= Received: by 10.64.251.20 with SMTP id y20mr283638qbh; Tue, 08 Nov 2005 20:14:53 -0800 (PST) Received: by 10.64.185.19 with HTTP; Tue, 8 Nov 2005 20:14:52 -0800 (PST) Message-ID: <9ab217670511082014w467ab180i@mail.gmail.com> Date: Tue, 8 Nov 2005 20:14:52 -0800 From: "Devon H. O'Dell" To: "ke.han" In-Reply-To: <437170B9.3020709@redstarling.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> <9ab217670511081836t7e21b0e3k@mail.gmail.com> <437170B9.3020709@redstarling.com> Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 04:21:41 -0000 2005/11/8, ke.han : > Devon H. O'Dell wrote: > >>I am aware of all this. This knowledge base article I reference (here > >>it is again: http://www.3ware.com/KB/article.aspx?id=3D14546 has the > >>source and instructions for the new driver. All that is needed is for > >>someone to compile it!!! I cannot compile this for 64 bit since I don'= t > >>have a working machine with EM64T until after I have a compiled driver. > >> > >>Is there anyone out there with an EM64T box that can download the sourc= e > >>and instructions and compile the driver?? > >> > >>thanks, Jon > > > > > > You can't use a module since the twa driver is in 6.0-RELEASE and the > > module won't load since it uses the same symbols. However, my > > coworker, Seth Kingsley compiled it today for 6.0-RELEASE and just > > gave me the CD, so if you can wait for a couple minutes, I'll put it > > up on http://www.sitetronics.com/~dodell/kernel-9550sx > > > > --Devon > > > > Thanks for the download...got it. why is your file 7m when the kernel > module I compiled for i386 is only 57k? Again, this is because you cannot load the twa module into a 6.0-RELEASE GENERIC kernel. The 6.0 GENERIC kernel already has the twa driver built into it, just without support for the SX cards. Thus you have to build the driver into the kernel (which is what Seth did -- that is a 6.0-RELEASE amd64 kernel with the `fixed' twa driver). > Also, are you saying that I must compile the driver into the kernel? Yes, because, as previously stated, the module will not load. The symbols in the twa module have the _same names_ as the symbols in the kernel. The krtld will detect this and refuse to load your module. > This means I first have to be able to install to a single drive on the > system first, right?? No, just boot the machine with the kernel I posted and before rebooting (after the install) make sure you copy that kernel over. > If this is the case, this gets me back to my other problem which is the > 6.0-RELEASE installer won't find my single hard drive (either EIDE or > SATA) which I have directly connected to the tyan i7520 mobo ;-( ...I > have posted this problem as a seperate discussion in paralle with this on= e. > > thanks, ke han If you do it as described above, you should have no such problem. --Devon From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 04:24:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CF916A41F for ; Wed, 9 Nov 2005 04:24:04 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D57343D46 for ; Wed, 9 Nov 2005 04:24:03 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by xproxy.gmail.com with SMTP id t10so122928wxc for ; Tue, 08 Nov 2005 20:24:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=drzBWTBHnR/Qswggx577rRn0GOaB3DCDyanYywKXlO2CCaVFxFx503n43ac6YD2modu7ijBH/zXx7f+T7umutcVL8Ibc3/5+R90wJNTd+/GnSu1qwfRN0kb+o5kfbbfeZwqZahRm5nOKS1NweOR0AQSBA0O2DHnT9ni6BcEIemg= Received: by 10.64.204.4 with SMTP id b4mr236508qbg; Tue, 08 Nov 2005 18:36:44 -0800 (PST) Received: by 10.64.185.19 with HTTP; Tue, 8 Nov 2005 18:36:44 -0800 (PST) Message-ID: <9ab217670511081836t7e21b0e3k@mail.gmail.com> Date: Tue, 8 Nov 2005 18:36:44 -0800 From: "Devon H. O'Dell" To: "ke.han" In-Reply-To: <43715294.3080604@redstarling.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 04:24:04 -0000 > I am aware of all this. This knowledge base article I reference (here > it is again: http://www.3ware.com/KB/article.aspx?id=3D14546 has the > source and instructions for the new driver. All that is needed is for > someone to compile it!!! I cannot compile this for 64 bit since I don't > have a working machine with EM64T until after I have a compiled driver. > > Is there anyone out there with an EM64T box that can download the source > and instructions and compile the driver?? > > thanks, Jon You can't use a module since the twa driver is in 6.0-RELEASE and the module won't load since it uses the same symbols. However, my coworker, Seth Kingsley compiled it today for 6.0-RELEASE and just gave me the CD, so if you can wait for a couple minutes, I'll put it up on http://www.sitetronics.com/~dodell/kernel-9550sx --Devon From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 21:37:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 921FA16A41F for ; Tue, 8 Nov 2005 21:37:44 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F64543D48 for ; Tue, 8 Nov 2005 21:37:44 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jA8LbeWl097917; Tue, 8 Nov 2005 15:37:40 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jA8Lbdkm097916; Tue, 8 Nov 2005 15:37:39 -0600 (CST) (envelope-from tinguely) Date: Tue, 8 Nov 2005 15:37:39 -0600 (CST) From: Mark Tinguely Message-Id: <200511082137.jA8Lbdkm097916@casselton.net> To: freebsd-current@freebsd.org, snezhko@indorsoft.ru In-Reply-To: X-Spam-Status: No, score=0.6 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net X-Mailman-Approved-At: Wed, 09 Nov 2005 05:26:10 +0000 Cc: max@love2party.net Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 21:37:44 -0000 This is great, you caught the kernel trashing a callout entry in uma_dbg. I cannot figure out how #14 linked the function sorecieved() to the inline function uma_zfree(). (thinking as I am typing) Could someone changed the recieve function call for this socket? In my opinion, you can remove the callout_check_callwheel function and calls. You want to always catch it before it corrupts, and that is done in the uma_dbg. Once you catch the corruption, we know it will panic in the near future, unless we are in the debugger long enough, for the timer to expire and be removed. I would completely delete the compile directory and "config" and do a fresh make. --Mark Tinguely From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:38:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50F8D16A41F for ; Wed, 9 Nov 2005 05:38:08 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D740543D48 for ; Wed, 9 Nov 2005 05:38:07 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp6-g19.free.fr (Postfix) with ESMTP id C6DD1962C for ; Wed, 9 Nov 2005 06:38:06 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA95bfxq031475; Wed, 9 Nov 2005 06:37:48 +0100 (CET) From: Thierry Herbelot To: "M. Warner Losh" , freebsd-current@freebsd.org Date: Wed, 9 Nov 2005 06:37:34 +0100 User-Agent: KMail/1.8.3 References: <200511081913.15042.thierry@herbelot.com> <200511082235.42725.thierry@herbelot.com> <20051108.150847.27281507.imp@bsdimp.com> In-Reply-To: <20051108.150847.27281507.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511090637.35392.thierry@herbelot.com> Cc: Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 05:38:08 -0000 Le Tuesday 8 November 2005 23:08, vous avez écrit : > > Did you get this crash spontaneously, or only when you suspended? Hello, The machine crashed all by itself (it was building the world and 'poof') The new world and kernel are built : let's go for a new cycle TfH From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:44:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 088D816A41F; Wed, 9 Nov 2005 05:44:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C2343D49; Wed, 9 Nov 2005 05:44:56 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 0DE644C7E9; Wed, 9 Nov 2005 05:45:09 +0000 (GMT) Received: from [192.168.46.52] (ppp166-27.static.internode.on.net [150.101.166.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id BF38F4C79E; Wed, 9 Nov 2005 05:45:07 +0000 (GMT) Message-ID: <43718CD4.9010909@roq.com> Date: Wed, 09 Nov 2005 16:44:52 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <43704138.2060007@roq.com> <200511081026.26576.jhb@freebsd.org> In-Reply-To: <200511081026.26576.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Jan Isley , freebsd-current@freebsd.org Subject: Re: amd64 6-release cd install, no serial console joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 05:44:57 -0000 John Baldwin wrote: >On Tuesday 08 November 2005 01:10 am, Michael VInce wrote: > > >>I am having similar problems on a Dell 2850 using 6.0R AMD64, but I >>believe its not something to do with my hardware although I don't have >>any other AMD64/EMT64 server to test on. >> >>I don't think I have actually done a ISO install via serial console on >>6.0-Release but I think I did on beta versions and it did work. >>I have been trying to do a PXE install and watching it all via serial >>console and it works fine as long as I dont use 6.0-Release files. Using >>a 6.0beta with PXE is working it fully boots the kernel and brings up >>sysinstall my only problem now is that when it tries to do a FTP install >>it goes for a 6.0beta5 directory which doesn't exist. When I try to use >>a 6.0-Release I can get it to boot loader and then get it to load the >>kernel but after that it disappears don't get any boot messages at all. >> >>Mike >> >> > >Have you checked to see if there are any device hints at the loader prompt? >It may be that /boot/device.hints is missing on the CD for some reason, and >the serial console requires at least one hint to set the flags on sio0 to >work properly. > > I checked on both of my PXE setups (which sit in side by side directories) and device.hints files on the 6.0-BETA5 and 6.0-RELEASE are identical In fact most of the /boot/ directory files in the Beta5 and Release are identical except for mfsroot.gz , loader.rc. The "beastie.4th" is in a extra file in Release I have now successfully used the Beta5 as a PXE boot installer and changed the Release name in sysinstall as Boris suggested to install the final release files. Mike From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 05:57:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9246B16A41F for ; Wed, 9 Nov 2005 05:57:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A81B43D46 for ; Wed, 9 Nov 2005 05:57:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA95u43A031168; Tue, 8 Nov 2005 22:56:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Nov 2005 22:56:35 -0700 (MST) Message-Id: <20051108.225635.25892608.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511090637.35392.thierry@herbelot.com> References: <200511082235.42725.thierry@herbelot.com> <20051108.150847.27281507.imp@bsdimp.com> <200511090637.35392.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 08 Nov 2005 22:56:04 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 05:57:49 -0000 In message: <200511090637.35392.thierry@herbelot.com> Thierry Herbelot writes: : Le Tuesday 8 November 2005 23:08, vous avez =E9crit : : > : > Did you get this crash spontaneously, or only when you suspended? : = : Hello, : = : The machine crashed all by itself (it was building the world and 'poo= f') The traceback you sent me said that it was a keyboard initialized suspend. : The new world and kernel are built : let's go for a new cycle Cool. Warner From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:03:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3AF316A41F for ; Wed, 9 Nov 2005 06:03:15 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by mx1.FreeBSD.org (Postfix) with SMTP id 7EC2C43D48 for ; Wed, 9 Nov 2005 06:03:15 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 78603 invoked from network); 9 Nov 2005 06:03:14 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 9 Nov 2005 06:03:14 -0000 Message-ID: <43719123.5080306@redstarling.com> Date: Wed, 09 Nov 2005 14:03:15 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Devon H. O'Dell" References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> <9ab217670511081836t7e21b0e3k@mail.gmail.com> <437170B9.3020709@redstarling.com> <9ab217670511082014w467ab180i@mail.gmail.com> In-Reply-To: <9ab217670511082014w467ab180i@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 06:03:16 -0000 Devon H. O'Dell wrote: > 2005/11/8, ke.han : > >>Devon H. O'Dell wrote: > > > No, just boot the machine with the kernel I posted and before > rebooting (after the install) make sure you copy that kernel over. > > Devon, Thanks for the help...sorry to be so dense but my brain must be a little fried right now. I do get it now ;-) The only two extra questions I need are: 1 - this is a kernel for amd64/em64t or i386? 2 - in order to boot from this kernel, do I burn this on a second cd from the 6.0 install CD and just swap the cds for the 3rd phase boot process? and then put the 6.0 install disk back in once I'm at the sysinstall screen? thanks again, ke han > > If you do it as described above, you should have no such problem. > > --Devon > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:05:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E24D16A41F for ; Wed, 9 Nov 2005 06:05:23 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 8FFE443D46 for ; Wed, 9 Nov 2005 06:05:22 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 12824 invoked from network); 9 Nov 2005 06:05:22 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.213.163 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 9 Nov 2005 06:05:21 -0000 Message-ID: <437191A2.9000603@redstarling.com> Date: Wed, 09 Nov 2005 14:05:22 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mjm@michaelmeltzer.com References: <20051109034356.60414.qmail@web30102.mail.mud.yahoo.com> In-Reply-To: <20051109034356.60414.qmail@web30102.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Vinod Kashyap Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 06:05:23 -0000 michael meltzer wrote: > >>It's the same driver (twa) for SX, and it's already >>in GENERIC. >>Automatic firmware download is disabled because it >>will make >>the driver too big to fit into installation >>floppies. >> >> > > > My apologies, it was sounding like a new driver, also > I was little quick remebering a few long nights I had. > FWIW once the source is in the tree might me nice that > the default build does load the driver. keep the card > in sync with cvsup -mjm > Who do I have to nudge to get this code in the tree? The source was available from 3ware support web site for at least a month before 6.0-RELEASE. thanks, ke han > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:18:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B825B16A41F for ; Wed, 9 Nov 2005 06:18:41 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5009F43D46 for ; Wed, 9 Nov 2005 06:18:41 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp1-g19.free.fr (Postfix) with ESMTP id 42B825E248 for ; Wed, 9 Nov 2005 07:18:39 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA96IXWn023334; Wed, 9 Nov 2005 07:18:34 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 9 Nov 2005 07:18:25 +0100 User-Agent: KMail/1.8.3 References: <200511082235.42725.thierry@herbelot.com> <200511090637.35392.thierry@herbelot.com> <20051108.225635.25892608.imp@bsdimp.com> In-Reply-To: <20051108.225635.25892608.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511090718.26573.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 06:18:41 -0000 Le Wednesday 9 November 2005 06:56, M. Warner Losh a écrit : > In message: <200511090637.35392.thierry@herbelot.com> > > Thierry Herbelot writes: > : Le Tuesday 8 November 2005 23:08, vous avez écrit : > : > Did you get this crash spontaneously, or only when you suspended? > : > : Hello, > : > : The machine crashed all by itself (it was building the world and 'poof') > > The traceback you sent me said that it was a keyboard initialized > suspend. I know, but I can tell you the panic occurred spontaneously (it was making the world, after booting with ACPI enabled) TfH From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:39:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B05616A420 for ; Wed, 9 Nov 2005 06:39:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BD7F43D45 for ; Wed, 9 Nov 2005 06:39:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA96akGA031447; Tue, 8 Nov 2005 23:36:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Nov 2005 23:37:18 -0700 (MST) Message-Id: <20051108.233718.87127181.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511090718.26573.thierry@herbelot.com> References: <200511090637.35392.thierry@herbelot.com> <20051108.225635.25892608.imp@bsdimp.com> <200511090718.26573.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 08 Nov 2005 23:36:47 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 06:39:39 -0000 In message: <200511090718.26573.thierry@herbelot.com> Thierry Herbelot writes: : Le Wednesday 9 November 2005 06:56, M. Warner Losh a =E9crit : : > In message: <200511090637.35392.thierry@herbelot.com> : > : > Thierry Herbelot writes: : > : Le Tuesday 8 November 2005 23:08, vous avez =E9crit : : > : > Did you get this crash spontaneously, or only when you suspende= d? : > : : > : Hello, : > : : > : The machine crashed all by itself (it was building the world and = 'poof') : > : > The traceback you sent me said that it was a keyboard initialized : > suspend. : = : I know, but I can tell you the panic occurred spontaneously (it was m= aking the = : world, after booting with ACPI enabled) with the same traceback? That's really weird. Warner From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:52:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F117316A41F for ; Wed, 9 Nov 2005 06:52:35 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A91B43D46 for ; Wed, 9 Nov 2005 06:52:35 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by xproxy.gmail.com with SMTP id t10so150174wxc for ; Tue, 08 Nov 2005 22:52:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G2VmkwJzfe8R4RjL3FENGewZh5UzcbRwTu0Ayr/JLIicavVhu6/HwUppIyKlllah5QB9TGMWsaLlUWlwU0Yhmog+dJHnCDwTkP3r13EvV0qlqdlCD2U7JQvyAsWAVv5ppppMbNuEsh5uiIALrGSE7HxmlEx/TmlRiP6ENm0D9OY= Received: by 10.65.218.2 with SMTP id v2mr423804qbq; Tue, 08 Nov 2005 22:52:34 -0800 (PST) Received: by 10.64.185.19 with HTTP; Tue, 8 Nov 2005 22:52:34 -0800 (PST) Message-ID: <9ab217670511082252s628db890j@mail.gmail.com> Date: Tue, 8 Nov 2005 22:52:34 -0800 From: "Devon H. O'Dell" To: "ke.han" In-Reply-To: <43719123.5080306@redstarling.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> <9ab217670511081836t7e21b0e3k@mail.gmail.com> <437170B9.3020709@redstarling.com> <9ab217670511082014w467ab180i@mail.gmail.com> <43719123.5080306@redstarling.com> Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 06:52:36 -0000 2005/11/8, ke.han : > Devon, > Thanks for the help...sorry to be so dense but my brain must be a little > fried right now. > I do get it now ;-) > The only two extra questions I need are: > 1 - this is a kernel for amd64/em64t or i386? > 2 - in order to boot from this kernel, do I burn this on a second cd > from the 6.0 install CD and just swap the cds for the 3rd phase boot > process? and then put the 6.0 install disk back in once I'm at the > sysinstall screen? > > thanks again, ke han No problem. The kernel is for AMD64. What you may be able to do is drop to the bootloader prompt and unload kernel. After that, you should be able to indeed load the kernel from the other CD, plop the original back in there and boot. Another suggestion would be to do a PXE boot, which may or may not be a bigger hassle for you. You could also just extract the ISO filesystem, replace the kernel and burn another install CD. I think you can also do this with an md mount of the ISO image (just recopy the kernel over) and burn the CD. Not sure on the last one though. --Devon From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 06:57:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01CF716A41F for ; Wed, 9 Nov 2005 06:57:29 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA8C43D45 for ; Wed, 9 Nov 2005 06:57:28 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp2-g19.free.fr (Postfix) with ESMTP id CCB98522E5 for ; Wed, 9 Nov 2005 07:57:27 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA96vId3031243; Wed, 9 Nov 2005 07:57:20 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 9 Nov 2005 07:57:10 +0100 User-Agent: KMail/1.8.3 References: <200511090637.35392.thierry@herbelot.com> <200511090718.26573.thierry@herbelot.com> <20051108.233718.87127181.imp@bsdimp.com> In-Reply-To: <20051108.233718.87127181.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511090757.11865.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 06:57:29 -0000 Le Wednesday 9 November 2005 07:37, M. Warner Losh a écrit : > : I know, but I can tell you the panic occurred spontaneously (it was > : making the world, after booting with ACPI enabled) > > with the same traceback? That's really weird. I'am also surprised, but this machine is mostly headless (even though it's a notebook, everything under -current is driven through a serial console or an ssh sesssion ; the display lid is closed, so even an accidental keypress is not possible) - strange ... TfH From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:15:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 876A316A429 for ; Wed, 9 Nov 2005 07:15:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4F2243D46 for ; Wed, 9 Nov 2005 07:15:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA97CkuS031714; Wed, 9 Nov 2005 00:12:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 09 Nov 2005 00:13:18 -0700 (MST) Message-Id: <20051109.001318.97142346.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511090757.11865.thierry@herbelot.com> References: <200511090718.26573.thierry@herbelot.com> <20051108.233718.87127181.imp@bsdimp.com> <200511090757.11865.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 09 Nov 2005 00:12:46 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 07:15:40 -0000 In message: <200511090757.11865.thierry@herbelot.com> Thierry Herbelot writes: : Le Wednesday 9 November 2005 07:37, M. Warner Losh a =E9crit : : = : > : I know, but I can tell you the panic occurred spontaneously (it w= as : > : making the world, after booting with ACPI enabled) : > : > with the same traceback? That's really weird. : = : I'am also surprised, but this machine is mostly headless (even though= it's a = : notebook, everything under -current is driven through a serial consol= e or an = : ssh sesssion ; the display lid is closed, so even an accidental keypr= ess is = : not possible) - strange ... Very very strange. Are you sure this isn't a dump from somebody else's laptop that is configured to user your swap device as its dump media? :-) Warner From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:24:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC5A716A420 for ; Wed, 9 Nov 2005 07:24:10 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E84A443D68 for ; Wed, 9 Nov 2005 07:24:06 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp3-g19.free.fr (Postfix) with ESMTP id 290A5373A3 for ; Wed, 9 Nov 2005 08:24:05 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jA97NvEC007366; Wed, 9 Nov 2005 08:23:58 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 9 Nov 2005 08:23:49 +0100 User-Agent: KMail/1.8.3 References: <200511090718.26573.thierry@herbelot.com> <200511090757.11865.thierry@herbelot.com> <20051109.001318.97142346.imp@bsdimp.com> In-Reply-To: <20051109.001318.97142346.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511090823.50903.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 07:24:11 -0000 Le Wednesday 9 November 2005 08:13, M. Warner Losh a écrit : > Very very strange. Are you sure this isn't a dump from somebody > else's laptop that is configured to user your swap device as its dump > media? :-) I wouldn't be so sure, now - anyhow, your patch seems to be a good cure, so we'll have to assume some gremlin tried to suspend the machine. TfH From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 07:27:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40CCC16A41F for ; Wed, 9 Nov 2005 07:27:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7BA443D46 for ; Wed, 9 Nov 2005 07:27:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA97Q8Bt031816; Wed, 9 Nov 2005 00:26:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 09 Nov 2005 00:26:40 -0700 (MST) Message-Id: <20051109.002640.03870111.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200511090823.50903.thierry@herbelot.com> References: <200511090757.11865.thierry@herbelot.com> <20051109.001318.97142346.imp@bsdimp.com> <200511090823.50903.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 09 Nov 2005 00:26:08 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: Attempting to sleep in interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 07:27:39 -0000 In message: <200511090823.50903.thierry@herbelot.com> Thierry Herbelot writes: : Le Wednesday 9 November 2005 08:13, M. Warner Losh a =E9crit : : = : > Very very strange. Are you sure this isn't a dump from somebody : > else's laptop that is configured to user your swap device as its du= mp : > media? :-) : = : I wouldn't be so sure, now - anyhow, your patch seems to be a good cu= re, so = : we'll have to assume some gremlin tried to suspend the machine. OK. I hate mysteries... Glad to see the patch fixes your problem. Warner From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 08:25:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC24116A41F for ; Wed, 9 Nov 2005 08:25:51 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C303B43D58 for ; Wed, 9 Nov 2005 08:25:50 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028726.msg for ; Wed, 09 Nov 2005 14:25:41 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 126749, updated: 7.11.2005] To: Mark Tinguely References: <200511082137.jA8Lbdkm097916@casselton.net> From: Victor Snezhko Date: Wed, 09 Nov 2005 14:25:37 +0600 In-Reply-To: <200511082137.jA8Lbdkm097916@casselton.net> (Mark Tinguely's message of "Tue, 8 Nov 2005 15:37:39 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Wed, 09 Nov 2005 14:25:41 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Cc: max@love2party.net, freebsd-current@freebsd.org Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 08:25:52 -0000 Mark Tinguely writes: > This is great, you caught the kernel trashing a callout entry > in uma_dbg. Hmm, not so fast... Look at the list output: 103 if ((u_int32_t)c == uma_junk) { 104 kdb_enter("trash_dtor: uma_junk found in a "\ 105 "callwheel element"); By the moment when I start traversing callwheel, it is already corrupted! (Or maybe modified by someone who doesn't hold the callout_lock) > I cannot figure out how #14 linked the function sorecieved() to > the inline function uma_zfree(). (thinking as I am typing) Could > someone changed the recieve function call for this socket? Maybe inline function introduces this mess? > In my opinion, you can remove the callout_check_callwheel function > and calls. Agreed, I just wanted to demonstrate that things are not so simple. > You want to always catch it before it corrupts, and that > is done in the uma_dbg. Unfortunately, uma_dbg catches already corrupted callwheel (or not catches anything at all, in this case ppp works) > Once you catch the corruption, we know it will panic in the near > future, unless we are in the debugger long enough, for the timer to > expire and be removed. Hmm, looks like it's really so. This needs additional checking. > I would completely delete the compile directory and "config" and > do a fresh make. This is exactly what I have done before submitting my report. Because I cvsdown'ed to 2005.10.21.16.30.00 to be independent of recent changes that would mess up something. I also tested on fresh current on Saturday or Sunday - backtrace was similar - may be different lines or something. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 08:35:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7105116A41F for ; Wed, 9 Nov 2005 08:35:57 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0705F43D46 for ; Wed, 9 Nov 2005 08:35:56 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EZlQN-0000Gn-IV; Wed, 09 Nov 2005 09:35:21 +0100 Date: Wed, 9 Nov 2005 09:35:52 +0100 From: Marcin Jessa To: Scott Long Message-Id: <20051109093552.3082c51b.lists@yazzy.org> In-Reply-To: <437145DF.2040508@samsco.org> References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.3 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 08:35:57 -0000 On Tue, 08 Nov 2005 17:42:07 -0700 Scott Long wrote: > Marcin Jessa wrote: > > Hi guys. > > > > I just came across an article of Mr. Greg Kroah-Hartman in his blog > > http://www.kroah.com/log/2005/11/03/ > > about generic kernel API which could make it possible for hardware > > vendors to supply us with their own drivers. > > To be honest I disagree with Greg and consider this a good idea. > > Especially if we had a system which could isolate each device driver > > running as a separate user-mode process so it would not bring down > > the entire OS in case the driver was buggy. > > An API like that would both boost up FreeBSD's popularity and make > > it possible to use a way larger variety of hardware. > > I mean, lets not fool ourselves, the majority of hardware vendors is > > not interested in revealing of their secrets publishing freely > > avaliable documentation of their products. > > We could have a new choice to use (or not) binary drivers the > > same way the popular commercial O.Ss do. > > What do you guys think? What is the view of the > > FreeBSD community on this metter? > > Could this be concerned as a good idea ? > > > > > > Cheers, > > Marcin Jessa. > > > Please don't take this the wrong way, but google for 'Universal Driver > Interface'. Yes, this topic comes up every few years. It sounds > like a good idea, but every OS has unique and incompatible ways of > doing things. You've misunderstood me Scott. I never meant it to be an universal API but a FreeBSD one only. I understand an universal closs-platform driver API would me a nearly impossible project. My idea is to create an API for binary vendor drivers to make it easier for hardware vendors to create FreeBSD drivers the same way they can do for Windows or Mac OS X. >Sure, it's easy to map malloc in FreeBSD to kmalloc in > Linux, but how do you map ithreads in FreeBSD and Solaris to Linux? > How do you map busdma in FreeBSD to busdma in NetBSD, let alone Linux > where there is little concept of a DMA abstraction? How do you map > newbus in FreeBSD to, um, nothing in Linux? How do you map VFS on > FreeBSD to VFS on Linux or Solaris? All of these things make such a > unification effort impossible to do without watering it down to where > it is either functionally useless or too slow and abstract to > matter. Ironically, Project Evil has bridged the gap the best, but > it limits its scope to the Windows NDIS API. It might be possible to > expand it to cover StorPort also, but forget about much more than > that. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 08:58:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DE116A41F for ; Wed, 9 Nov 2005 08:58:38 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC90243D45 for ; Wed, 9 Nov 2005 08:58:34 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028737.msg for ; Wed, 09 Nov 2005 14:58:26 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 126749, updated: 7.11.2005] To: freebsd-current@freebsd.org References: <200511082313.jA8NDbft005916@casselton.net> From: Victor Snezhko Date: Wed, 09 Nov 2005 14:58:21 +0600 In-Reply-To: <200511082313.jA8NDbft005916@casselton.net> (Mark Tinguely's message of "Tue, 8 Nov 2005 17:13:37 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Wed, 09 Nov 2005 14:58:26 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 08:58:38 -0000 Mark Tinguely writes: > before too much work is done (below), could you print out the callout > that is being freed but active and the memory around it (before it > is overwritten by "deadc0de"). It may tell us which callout that it > is or was. I would be happy to do so but as I have just said, I call not the callout that is freed but the other one already filled with uma_trash... If I'm mistaken, please correct me. > If we cannot glean who the callout is/was, then more tests can be > added to determine if the UMA is allocating memory chained to the callout > or if the MBUF chain is corrupted. Sorry, I'm not familiar enough with UMA/mbufs (at the moment) to make such tests myself. With callouts it was simple - I watched into kern_timeout.c and read timeout(9) manpage. Now I'm reading appropriate manpages but it'l take me a while before I grasp all the dependencies. And reading manpages, I guess, won't be enough. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 09:38:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2F9816A41F for ; Wed, 9 Nov 2005 09:38:23 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F3643D48 for ; Wed, 9 Nov 2005 09:38:22 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D559.dip.t-dialin.net [84.165.213.89]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id jA99Foik084424; Wed, 9 Nov 2005 10:15:56 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id jA99c4Xb073768; Wed, 9 Nov 2005 10:38:04 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by netchild.homeip.net (Horde MIME library) with HTTP; Wed, 09 Nov 2005 10:38:03 +0100 Message-ID: <20051109103803.wfqjg0zj28cc4wsg@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 09 Nov 2005 10:38:03 +0100 From: Alexander Leidinger To: Frode Nordahl References: <4370D11F.3070306@wmptl.com> <54db43990511081138p86058bfrb5a9786261a0e6b2@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: Bob Johnson , Nathan Vidican , current@freebsd.org Subject: Re: USB 2.0 Support (re-post, more info) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 09:38:23 -0000 Frode Nordahl wrote: > I have yet to test pulling mounted drives during I/O and other nasty > stuff :-) No need to do that. Don't report the panic if you do it, it's known. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Toilet Toup'ee, n.: Any shag carpet that causes the lid to become top-heavy, thus creating endless annoyance to male users. -- Rich Hall, "Sniglets" From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 09:39:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F3916A41F for ; Wed, 9 Nov 2005 09:39:23 +0000 (GMT) (envelope-from fjoe@neo.samodelkin.net) Received: from neo.samodelkin.net (samodelkin.net [195.62.0.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D7B43D45 for ; Wed, 9 Nov 2005 09:39:22 +0000 (GMT) (envelope-from fjoe@neo.samodelkin.net) Received: by neo.samodelkin.net (Postfix, from userid 1000) id 6122A17022; Wed, 9 Nov 2005 15:39:20 +0600 (NOVT) Date: Wed, 9 Nov 2005 15:39:20 +0600 From: Max Khon To: Marcin Jessa Message-ID: <20051109093920.GA45506@samodelkin.net> References: <20051108232855.2d1b7df5.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051108232855.2d1b7df5.lists@yazzy.org> User-Agent: Mutt/1.4.2i Cc: FreeBSD-Current Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 09:39:23 -0000 Hi! On Tue, Nov 08, 2005 at 11:28:55PM +0000, Marcin Jessa wrote: > I just came across an article of Mr. Greg Kroah-Hartman in his blog > http://www.kroah.com/log/2005/11/03/ > about generic kernel API which could make it possible for hardware > vendors to supply us with their own drivers. > To be honest I disagree with Greg and consider this a good idea. > Especially if we had a system which could isolate each device driver > running as a separate user-mode process so it would not bring down the > entire OS in case the driver was buggy. > An API like that would both boost up FreeBSD's popularity and make it > possible to use a way larger variety of hardware. > I mean, lets not fool ourselves, the majority of hardware vendors is > not interested in revealing of their secrets publishing freely > avaliable documentation of their products. > We could have a new choice to use (or not) binary drivers the > same way the popular commercial O.Ss do. > What do you guys think? What is the view of the > FreeBSD community on this metter? > Could this be concerned as a good idea ? You can extend ndisulator so that it is possible to use other kinds of win32 drivers under FreeBSD. /fjoe From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 09:48:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E08B16A41F for ; Wed, 9 Nov 2005 09:48:05 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F0243D45 for ; Wed, 9 Nov 2005 09:48:04 +0000 (GMT) (envelope-from nikruzhan@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so107430nzo for ; Wed, 09 Nov 2005 01:48:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=lgV4cGMOYRLDQdVqdiD6bO3/f1m3bLGG61uh1w+bCGtzuKI/AGSBzlQa1FIw9NQNVa4hPSokz6xWIxLGJ/iomxCjMxA0asb2TqAfCfSwwxKJ3RuoFYhJSxmUavP2zA7QtbOBrUAHoLFk+M8Kgy48ynDnrq8k2UzZ3twBrPOZMLk= Received: by 10.37.21.41 with SMTP id y41mr330740nzi; Wed, 09 Nov 2005 01:48:04 -0800 (PST) Received: by 10.36.224.36 with HTTP; Wed, 9 Nov 2005 01:48:04 -0800 (PST) Message-ID: <60ffc71f0511090148i7a35de05i4274b54feae07276@mail.gmail.com> Date: Wed, 9 Nov 2005 17:48:04 +0800 From: Nik To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: One to one mappings issues using IPnat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 09:48:05 -0000 Hi, I'm using ipnat for one to one mappings in my FreeBSD router using IPnat. I got several interfaces plus Vlans ; rl0 - Local (192.168.0.x), em0, em1, em2, em3 - External (internet), em4, vlan0, vlan1, vlan2, vlan3, vlan4, vlan5, vlan6, vlan7, vlan8, vlan9 - DMZ = ( 202.xxx.10.x). my ipnat.rules ; map em3 192.168.0.0/24 -> 0/32 portmap tcp/udp auto map em3 192.168.0.0/24 -> 0/32 # Server bimap em3 192.168.0.22/32 -> 202.xxx.10.7/32 bimap vlan2 192.168.0.22/32 -> 202.xxx.10.7/32 bimap vlan3 192.168.0.22/32 -> 202.xxx.10.7/32 bimap vlan4 192.168.0.22/32 -> 202.xxx.10.7/32 bimap vlan5 192.168.0.22/32 -> 202.xxx.10.7/32 bimap rl0 192.168.0.22/32 -> 202.xxx.10.7/32 202.xxx.10.7/32 was included in vlan9, my local already can ping to 202.xxx.10.7 and that's mean it's working at Lan but the problem is I can't ping 202.xxx.10.7 from another same subnet ip eg: 202.xxx.10.10 and it give me this result ; [root@SatelliteVod ~]# ping 202.xxx.10.7 PING 202.xxx.10.7 (202.xxx.10.7) 56(84) bytes of data. >From 202.xxx.10.10 icmp_seq=3D0 Destination Host Unreachable >From 202.xxx.10.10 icmp_seq=3D1 Destination Host Unreachable >From 202.xxx.10.10 icmp_seq=3D2 Destination Host Unreachable Also I can't ping 202.xxx.10.7 from router itself, it's give me this result ; > ping 202.xxx.10.7 PING 202.xxx.10.7 (202.xxx.10.7): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down --- 202.xxx.10.7 ping statistics --- 9 packets transmitted, 0 packets received, 100% packet loss There's no problem when I try to ping the server from outside. I just pass all out and pass in all in my ipf.rules so I think there's no problem with ipfilter. Thanks, Nik. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 10:09:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F5DA16A420 for ; Wed, 9 Nov 2005 10:09:06 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C6843D49 for ; Wed, 9 Nov 2005 10:09:05 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EZmsX-0004UX-MP; Wed, 09 Nov 2005 11:08:30 +0100 Date: Wed, 9 Nov 2005 11:09:03 +0100 From: Marcin Jessa To: Max Khon Message-Id: <20051109110903.583bb72d.lists@yazzy.org> In-Reply-To: <20051109093920.GA45506@samodelkin.net> References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109093920.GA45506@samodelkin.net> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.3 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 10:09:06 -0000 On Wed, 9 Nov 2005 15:39:20 +0600 Max Khon wrote: > Hi! > > On Tue, Nov 08, 2005 at 11:28:55PM +0000, Marcin Jessa wrote: > > > I just came across an article of Mr. Greg Kroah-Hartman in his blog > > http://www.kroah.com/log/2005/11/03/ > > about generic kernel API which could make it possible for hardware > > vendors to supply us with their own drivers. > > To be honest I disagree with Greg and consider this a good idea. > > Especially if we had a system which could isolate each device driver > > running as a separate user-mode process so it would not bring down > > the entire OS in case the driver was buggy. > > An API like that would both boost up FreeBSD's popularity and make > > it possible to use a way larger variety of hardware. > > I mean, lets not fool ourselves, the majority of hardware vendors is > > not interested in revealing of their secrets publishing freely > > avaliable documentation of their products. > > We could have a new choice to use (or not) binary drivers the > > same way the popular commercial O.Ss do. > > What do you guys think? What is the view of the > > FreeBSD community on this metter? > > Could this be concerned as a good idea ? > > You can extend ndisulator so that it is possible to use other kinds of > win32 drivers under FreeBSD. Sure, but the point is to use native FreeBSD drivers, even if they were in closed source binary form and not drivers written for an entirely different O.S. Marcin From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 12:20:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E374B16A41F for ; Wed, 9 Nov 2005 12:20:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9935B43D46 for ; Wed, 9 Nov 2005 12:20:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 16BCA46B7C; Wed, 9 Nov 2005 07:20:15 -0500 (EST) Date: Wed, 9 Nov 2005 12:20:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marcin Jessa In-Reply-To: <20051109110903.583bb72d.lists@yazzy.org> Message-ID: <20051109121720.M39365@fledge.watson.org> References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109093920.GA45506@samodelkin.net> <20051109110903.583bb72d.lists@yazzy.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, Max Khon Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 12:20:16 -0000 On Wed, 9 Nov 2005, Marcin Jessa wrote: > Sure, but the point is to use native FreeBSD drivers, even if they were > in closed source binary form and not drivers written for an entirely > different O.S. I think there is general agreement that it would be nice to be able to offer both relatively static APIs and ABIs to device driver writers writing device drivers for FreeBSD. However, with the massive changes in kernel architecture over the last 4-5 years as part of SMPng and the threading work, that simply hasn't been possible. We do attempt to keep the API and ABI for device drivers relatively stable over the lifetime of a major release (i.e., 4.*, 5.*, 6.*) but even that runs into occasional problems. My hope is that in the next year or so, things will settle down significantly as we begin to flush the last of the non-MPSAFE drivers from the system, and reach a point where all device drivers can use consistent synchronization. Among other things, we have an item scheduled for the FreeBSD developer summit at EuroBSDCon to nail down parts of the network device driver API for this purpose. I.e., there is interest in what has been proposed, but we're not quite at a point where we can nail down the API in a more permanent way. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 13:53:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB06716A41F; Wed, 9 Nov 2005 13:53:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4080D43D46; Wed, 9 Nov 2005 13:53:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jA9DqwK6023574; Wed, 9 Nov 2005 08:52:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id jA9Dqw9g063580; Wed, 9 Nov 2005 08:52:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2AEC17302F; Wed, 9 Nov 2005 08:52:58 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051109135258.2AEC17302F@freebsd-current.sentex.ca> Date: Wed, 9 Nov 2005 08:52:58 -0500 (EST) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 13:53:01 -0000 TB --- 2005-11-09 12:36:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-09 12:36:49 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-11-09 12:36:49 - cleaning the object tree TB --- 2005-11-09 12:37:17 - checking out the source tree TB --- 2005-11-09 12:37:17 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-11-09 12:37:17 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-09 12:44:18 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-09 12:44:18 - cd /src TB --- 2005-11-09 12:44: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 TB --- 2005-11-09 13:48:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-09 13:48:42 - cd /src TB --- 2005-11-09 13:48:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 13:48:42 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/subr_msgbuf.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/subr_param.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/subr_pcpu.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/kern/subr_power.c /src/sys/kern/subr_power.c: In function `power_pm_deferred_fn': /src/sys/kern/subr_power.c:45: warning: cast from pointer to integer of different size /src/sys/kern/subr_power.c: In function `power_pm_suspend': /src/sys/kern/subr_power.c:86: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/alpha/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-09 13:52:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-09 13:52:57 - ERROR: failed to build generic kernel TB --- 2005-11-09 13:52:57 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 13:58:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 326C716A41F for ; Wed, 9 Nov 2005 13:58:49 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90AEA43D46 for ; Wed, 9 Nov 2005 13:58:48 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jA9Dwi0U045662; Wed, 9 Nov 2005 07:58:44 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jA9DwiC0045661; Wed, 9 Nov 2005 07:58:44 -0600 (CST) (envelope-from tinguely) Date: Wed, 9 Nov 2005 07:58:44 -0600 (CST) From: Mark Tinguely Message-Id: <200511091358.jA9DwiC0045661@casselton.net> To: snezhko@indorsoft.ru, tinguely@casselton.net In-Reply-To: X-Spam-Status: No, score=0.6 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net Cc: max@love2party.net, freebsd-current@freebsd.org Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 13:58:49 -0000 Thank-you for correcting me, I mistakenly did not look at which case was caught in the trash_dtor(). I also was not thinking MBUF when I suggested trace locations. m_sanity() in kern/uipc_mbuf.c will also set "0xdeadc0de" if the "sanitize" option is requested. But common sense says that your trash_dtor() code should catch this before it gets set, but if you wish to test there also it would put my mind at ease. In the mean time, I will look for callouts that are not stopped before they are freed. So far, I found the &sp->ifstart_callout in the file net/if_spppsubr.c started but not stopped before freed, but you are not using that routine. I will concentrate on the files that you listed were changed. --Mark Tinguely From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 15:36:54 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60EBC16A41F; Wed, 9 Nov 2005 15:36:54 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E37A43D46; Wed, 9 Nov 2005 15:36: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.4/8.13.4) with ESMTP id jA9Faq60035912; Wed, 9 Nov 2005 10:36:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jA9Faqux053750; Wed, 9 Nov 2005 10:36:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 23B5F7302F; Wed, 9 Nov 2005 10:36:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051109153652.23B5F7302F@freebsd-current.sentex.ca> Date: Wed, 9 Nov 2005 10:36:52 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 15:36:54 -0000 TB --- 2005-11-09 13:52:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-09 13:52:58 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-11-09 13:52:58 - cleaning the object tree TB --- 2005-11-09 13:53:36 - checking out the source tree TB --- 2005-11-09 13:53:36 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-11-09 13:53:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-09 14:00:19 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-09 14:00:19 - cd /src TB --- 2005-11-09 14:00: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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-11-09 15:30:40 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-09 15:30:40 - cd /src TB --- 2005-11-09 15:30:40 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 9 15:30:41 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/kern/subr_msgbuf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/kern/subr_param.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/kern/subr_pcpu.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/kern/subr_power.c /src/sys/kern/subr_power.c: In function `power_pm_deferred_fn': /src/sys/kern/subr_power.c:45: warning: cast from pointer to integer of different size /src/sys/kern/subr_power.c: In function `power_pm_suspend': /src/sys/kern/subr_power.c:86: warning: cast to pointer from integer of different size *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-09 15:36:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-09 15:36:51 - ERROR: failed to build generic kernel TB --- 2005-11-09 15:36:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 16:33:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D546E16A41F for ; Wed, 9 Nov 2005 16:33:08 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04E2E43D45 for ; Wed, 9 Nov 2005 16:33:07 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028833.msg for ; Wed, 09 Nov 2005 22:33:00 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 126749, updated: 7.11.2005] To: freebsd-current@freebsd.org References: <200511091358.jA9DwiC0045661@casselton.net> From: Victor Snezhko Date: Wed, 09 Nov 2005 22:32:56 +0600 In-Reply-To: <200511091358.jA9DwiC0045661@casselton.net> (Mark Tinguely's message of "Wed, 9 Nov 2005 07:58:44 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Wed, 09 Nov 2005 22:33:00 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Cc: Mark Tinguely Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 16:33:08 -0000 Mark Tinguely writes: > I also was not thinking MBUF when I suggested trace locations. m_sanity() > in kern/uipc_mbuf.c will also set "0xdeadc0de" if the "sanitize" > option is requested. Now I have a current of 2005.10.21.16.25.00, and there is no deadcode there. Only a comment stating that deadc0de'ing would be not bad. > But common sense says that your trash_dtor() > code should catch this before it gets set, but if you wish to test > there also it would put my mind at ease. Sure. I have already submitted a PR(kern/88725) with all the results I have so far, and when I find all the other places I'll make a followup to it. > In the mean time, I will look for callouts that are not stopped before > they are freed. So far, I found the &sp->ifstart_callout in the file > net/if_spppsubr.c started but not stopped before freed, but you are > not using that routine. I will concentrate on the files that you listed > were changed. Yes, it's right. This commit needs a serious checking even if we'll fix my issue with ppp. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 17:32:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3F0116A41F; Wed, 9 Nov 2005 17:32:11 +0000 (GMT) (envelope-from pckizer@nostrum.com) Received: from nostrum.com (magus.nostrum.com [69.5.195.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C90843D46; Wed, 9 Nov 2005 17:32:11 +0000 (GMT) (envelope-from pckizer@nostrum.com) Received: from [165.91.250.64] (magus.tamu.edu [165.91.250.64]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA9HVcON054491 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Nov 2005 11:31:39 -0600 (CST) (envelope-from pckizer@nostrum.com) In-Reply-To: <0906B09C-B5A2-402E-BF39-57EBB20B2D4F@nostrum.com> References: <200510191623.j9JGNSfr007356@magus.nostrum.com> <20051019175020.S60849@fledge.watson.org> <20051025110453.L6720@fledge.watson.org> <2E18CEAE-2A72-4387-B92E-DAED7CC7FACD@nostrum.com> <33E53AA7-2A01-4BBE-9674-8F54E008D0A8@nostrum.com> <0906B09C-B5A2-402E-BF39-57EBB20B2D4F@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <425C901E-3315-41EC-B2D9-C372A2110FF0@nostrum.com> Content-Transfer-Encoding: 7bit From: Philip Kizer Date: Wed, 9 Nov 2005 11:31:37 -0600 To: Philip Kizer X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 165.91.250.64 is authenticated by a trusted mechanism) Cc: freebsd-current@freebsd.org Subject: Re: Problem remains with FreeBSD 6.0-RELEASE as seen in RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 17:32:12 -0000 On Oct 29, 2005, at 11:01, Philip Kizer wrote: > Well, it's been a few days since the last time I heard from anyone > that had been helping me with this and I only recall seeing one > diagnostic patch to apply (that does not seem to have been > triggered in subsequent hangs). > Have there been any more patches I've missed that would help either > the problem or diagnostics? Well, with 6.0 going production, I updated my test system to that: FreeBSD host6 6.0-STABLE FreeBSD 6.0-STABLE #2: Tue Nov 8 08:40:32 CST 2005 since I figured you would do most of your development/patching against something more recent than RC2. I have now had another live-lock after upgrading: http://www.nostrum.com/hang/hang.RELENG_6-trace-2005-11-09-0.txt Any other suggestions or pointers on how to identify this livelock? As an added point, during boot I did see this LOR: Additional TCP options:. Starting background file system checks in 60 seconds. Tue Nov 8 15:31:14 CST 2005 FreeBSD/i386 (host6) (ttyd0) login: lock order reversal: 1st 0xc0982be0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_kern.c:295 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0937670,c0937d00,c08c4344) at 0xc064d9b1 = kdb_backtrace+0x29 witness_checkorder(c1060144,9,c0879ac1,127) at 0xc065795c = witness_checkorder+0x5b0 _mtx_lock_flags(c1060144,0,c0879ac1,127) at 0xc062df1f = _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c0879ac1,127) at 0xc078dda6 = _vm_map_lock+0x26 kmem_malloc(c10600c0,1000,1,e6a03ba4,c078605d) at 0xc078d432 = kmem_malloc+0x32 page_alloc(c104a960,1000,e6a03b97,1,c06572a0) at 0xc078647e = page_alloc+0x1a slab_zalloc(c104a960,1,0,c3dd0680,c10491c8) at 0xc078605d = slab_zalloc+0xa1 uma_zone_slab(c104a960,1,1,10,6ecf) at 0xc07875d0 = uma_zone_slab+0xe8 uma_zalloc_bucket(c104a960,1) at 0xc07877e0 = uma_zalloc_bucket+0x12c uma_zalloc_arg(c104a960,0,1) at 0xc078749c = uma_zalloc_arg+0x2dc malloc(800,c08fee40,1,105,c1044460) at 0xc062c38a = malloc+0xae hash_alloc(e6a03c74,c1044468,0,c0878d7a,1ab) at 0xc07859f9 = hash_alloc+0x29 zone_timeout(c1040b40) at 0xc0785912 = zone_timeout+0x7e zone_foreach(c0785894,e6a03ce8,c0641065,0,c0785860) at 0xc0786df7 = zone_foreach+0x37 uma_timeout(0) at 0xc0785872 = uma_timeout+0x12 softclock(0) at 0xc0641065 = softclock+0x211 ithread_loop(c34d6c00,e6a03d38,c34d6c00,c06234c0,0) at 0xc0623604 = ithread_loop+0x144 fork_exit(c06234c0,c34d6c00,e6a03d38) at 0xc0622a10 = fork_exit+0xa0 fork_trampoline() at 0xc07e39fc = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe6a03d6c, ebp = 0 --- FreeBSD/i386 (host6) (ttyd0) login: Thank you, Philip From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 18:26:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636C616A41F for ; Wed, 9 Nov 2005 18:26:37 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1994E43D73 for ; Wed, 9 Nov 2005 18:26:31 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 82853 invoked by uid 89); 9 Nov 2005 18:26:30 -0000 Received: by simscan 1.1.0 ppid: 82838, pid: 82847, t: 2.5882s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Nov 2005 18:26:27 -0000 Message-ID: <43723F49.9010109@ultra-secure.de> Date: Wed, 09 Nov 2005 19:26:17 +0100 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=7.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Subject: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 18:26:37 -0000 Hello, this is on a dual 1.2 GHz Supermicro P3TDE6 board. Sorry, I can't provide more details, just wanted to let you know. I have little time, so I just removed the RAM. The machine is fine with 1 or 2 GB RAM. cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 18:44:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A21316A41F for ; Wed, 9 Nov 2005 18:44:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E430E43D99 for ; Wed, 9 Nov 2005 18:44:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7B68446B4F; Wed, 9 Nov 2005 13:44:47 -0500 (EST) Date: Wed, 9 Nov 2005 18:44:47 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Philip Kizer In-Reply-To: <425C901E-3315-41EC-B2D9-C372A2110FF0@nostrum.com> Message-ID: <20051109184311.Y85371@fledge.watson.org> References: <200510191623.j9JGNSfr007356@magus.nostrum.com> <20051019175020.S60849@fledge.watson.org> <20051025110453.L6720@fledge.watson.org> <2E18CEAE-2A72-4387-B92E-DAED7CC7FACD@nostrum.com> <33E53AA7-2A01-4BBE-9674-8F54E008D0A8@nostrum.com> <0906B09C-B5A2-402E-BF39-57EBB20B2D4F@nostrum.com> <425C901E-3315-41EC-B2D9-C372A2110FF0@nostrum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Problem remains with FreeBSD 6.0-RELEASE as seen in RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2005 18:44:54 -0000 On Wed, 9 Nov 2005, Philip Kizer wrote: > On Oct 29, 2005, at 11:01, Philip Kizer wrote: >> Well, it's been a few days since the last time I heard from anyone that had >> been helping me with this and I only recall seeing one diagnostic patch to >> apply (that does not seem to have been triggered in subsequent hangs). >> Have there been any more patches I've missed that would help either the >> problem or diagnostics? > > Well, with 6.0 going production, I updated my test system to that: > FreeBSD host6 6.0-STABLE FreeBSD 6.0-STABLE #2: Tue Nov 8 08:40:32 > CST 2005 > > since I figured you would do most of your development/patching against > something more recent than RC2. > > I have now had another live-lock after upgrading: > > http://www.nostrum.com/hang/hang.RELENG_6-trace-2005-11-09-0.txt > Any other suggestions or pointers on how to identify this livelock? This looks like much the same issue in the UNIX domain sockets. I have been looking at executing unp_gc in a deferred context, and have an initial patch which I need to test some before I send to you. Hopefully it will be ready for you to try out in a day or two. > As an added point, during boot I did see this LOR: This is likely unrelated to the problem you're experiencing, and has been reported previously. I think a workaround or fix for this may have been committed to HEAD, but would need to check the logs and see. It should be non-harmful. Thanks, Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 18:58:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D47A16A420 for ; Wed, 9 Nov 2005 18:58:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9414743D53 for ; Wed, 9 Nov 2005 18:58:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 09 Nov 2005 10:58:14 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <437246C5.2030607@elischer.org> Date: Wed, 09 Nov 2005 10:58:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> <20051109093552.3082c51b.lists@yazzy.org> In-Reply-To: <20051109093552.3082c51b.lists@yazzy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 18:58:15 -0000 Marcin Jessa wrote: >On Tue, 08 Nov 2005 17:42:07 -0700 >Scott Long wrote: > > > >>Marcin Jessa wrote: >> >> >>>Hi guys. >>> >>>I just came across an article of Mr. Greg Kroah-Hartman in his blog >>>http://www.kroah.com/log/2005/11/03/ >>>about generic kernel API which could make it possible for hardware >>>vendors to supply us with their own drivers. >>>To be honest I disagree with Greg and consider this a good idea. >>>Especially if we had a system which could isolate each device driver >>>running as a separate user-mode process so it would not bring down >>>the entire OS in case the driver was buggy. >>>An API like that would both boost up FreeBSD's popularity and make >>>it possible to use a way larger variety of hardware. >>>I mean, lets not fool ourselves, the majority of hardware vendors is >>>not interested in revealing of their secrets publishing freely >>>avaliable documentation of their products. >>>We could have a new choice to use (or not) binary drivers the >>>same way the popular commercial O.Ss do. >>>What do you guys think? What is the view of the >>>FreeBSD community on this metter? >>>Could this be concerned as a good idea ? >>> >>> >>>Cheers, >>>Marcin Jessa. >>> >>> >>Please don't take this the wrong way, but google for 'Universal Driver >>Interface'. Yes, this topic comes up every few years. It sounds >>like a good idea, but every OS has unique and incompatible ways of >>doing things. >> >> > >You've misunderstood me Scott. >I never meant it to be an universal API but a FreeBSD one only. >I understand an universal closs-platform driver API would me a nearly >impossible project. >My idea is to create an API for binary vendor drivers to make it >easier for hardware vendors to create FreeBSD drivers the same way >they can do for Windows or Mac OS X. > > > well, you could port the Darwin driver interface in the form of a shim, or extend "project evil" to cover more kinds of drivers.. > > >>Sure, it's easy to map malloc in FreeBSD to kmalloc in >>Linux, but how do you map ithreads in FreeBSD and Solaris to Linux? >>How do you map busdma in FreeBSD to busdma in NetBSD, let alone Linux >>where there is little concept of a DMA abstraction? How do you map >>newbus in FreeBSD to, um, nothing in Linux? How do you map VFS on >>FreeBSD to VFS on Linux or Solaris? All of these things make such a >>unification effort impossible to do without watering it down to where >>it is either functionally useless or too slow and abstract to >>matter. Ironically, Project Evil has bridged the gap the best, but >>it limits its scope to the Windows NDIS API. It might be possible to >>expand it to cover StorPort also, but forget about much more than >>that. >> >> >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 19:20:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3274116A41F for ; Wed, 9 Nov 2005 19:20:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98A2743D45 for ; Wed, 9 Nov 2005 19:20:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jA9JKsnk065987 for ; Wed, 9 Nov 2005 13:20:54 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43724C11.5090201@centtech.com> Date: Wed, 09 Nov 2005 13:20:49 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1166/Mon Nov 7 13:01:45 2005 on mh2.centtech.com X-Virus-Status: Clean Subject: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 19:20:56 -0000 I've been having issues lately when trying to bring up a new interface. It's a hard problem to actually see, because it makes my machine instantly reboot. Here's what I see: Normally, I use ath0 for wireless, and occasionally I use em0. Recently, when I was at a location with no wireless and no dhcp support, I powered up my laptop, plugged in to em0, and did an ifconfig em0 xxx. After a few seconds, the system spontaneously reboots. I figured out that killing dhclient on that interface before attempting to manually configure it helped. Now, I also tried to connect using ppp to a GPRS network (via bluetooth through my cell phone). This used to work just fine, probably a few months ago. This time, I killed all dhclients, connected the bluetooth pieces, and then ran rfcomm_pppd, which creates a tun0 interface. When the interface was created, and brought up without dhclient, everything worked ok. When I accidentally left dhclient running, and tun0 was created, when the device got it's IP address, machine rebooted. I have various machine logs/dmesg/etc here: http://www.googlebit.com/freebsd/ (labeled by date - look for the most current versions) I'm running 7.0-CURRENT as of a few days ago. I have all the debugging, WITNESS, and other flags set. Any ideas? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 19:25:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D91116A41F for ; Wed, 9 Nov 2005 19:25:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B30243D46 for ; Wed, 9 Nov 2005 19:25:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA9JPTkA005692; Wed, 9 Nov 2005 12:25:30 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43724D29.906@samsco.org> Date: Wed, 09 Nov 2005 12:25:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> <20051109093552.3082c51b.lists@yazzy.org> In-Reply-To: <20051109093552.3082c51b.lists@yazzy.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 19:25:33 -0000 Marcin Jessa wrote: > On Tue, 08 Nov 2005 17:42:07 -0700 > Scott Long wrote: > > >>Marcin Jessa wrote: >> >>>Hi guys. >>> >>>I just came across an article of Mr. Greg Kroah-Hartman in his blog >>>http://www.kroah.com/log/2005/11/03/ >>>about generic kernel API which could make it possible for hardware >>>vendors to supply us with their own drivers. >>>To be honest I disagree with Greg and consider this a good idea. >>>Especially if we had a system which could isolate each device driver >>>running as a separate user-mode process so it would not bring down >>>the entire OS in case the driver was buggy. >>>An API like that would both boost up FreeBSD's popularity and make >>>it possible to use a way larger variety of hardware. >>>I mean, lets not fool ourselves, the majority of hardware vendors is >>>not interested in revealing of their secrets publishing freely >>>avaliable documentation of their products. >>>We could have a new choice to use (or not) binary drivers the >>>same way the popular commercial O.Ss do. >>>What do you guys think? What is the view of the >>>FreeBSD community on this metter? >>>Could this be concerned as a good idea ? >>> >>> >>>Cheers, >>>Marcin Jessa. >> >> >>Please don't take this the wrong way, but google for 'Universal Driver >>Interface'. Yes, this topic comes up every few years. It sounds >>like a good idea, but every OS has unique and incompatible ways of >>doing things. > > > You've misunderstood me Scott. > I never meant it to be an universal API but a FreeBSD one only. > I understand an universal closs-platform driver API would me a nearly > impossible project. > My idea is to create an API for binary vendor drivers to make it > easier for hardware vendors to create FreeBSD drivers the same way > they can do for Windows or Mac OS X. > > Yes, I did misunderstand, sorry. So you're asking for a generic, stable kernel API for drivers? In some ways, this already exists. We decided last year that we would keep kernel APIs stable and essentially 'frozen' for -STABLE branches. So the API that we have with 6.0 will remain unchanged for 6.1, 6.2, etc. There is room for exceptions here so long as they are well documented, justified, and complete, but I expect this to be very, very rare. Where this breaks down is in moving from 6.x to 7.0. We make no guarantees there for binary or source compatiblity. Apple is trying to address with problem with KPI's. There are obvious advantages to this, but the cost is quite high. It took them a number of years to go through the system and essentially re-write most of it. And it's still really only a theory; porting from 10.3 to 10.4 is hard because you have to adopt the KPIs in your code, and no one has seen 10.5 yet to decide if the KPI is really the same there. And, what do you do when you need to change an interface in order to make it faster or more capable? Do you shim it with a KPI and deal with the mess of trying to hide the differences under the covers? There are a lot of places in the SCSI and network driver APIs right now where changes can and should be made in order to get keep them useful. Loosing the flexibilty to do that between major releases will make the OS stagnate. I'm hoping that the guarantees that we have now are a good compromise. They stand in the middle between OSX at one end (strict compatiblity through generic APIs) and Linux at the other end (no guarantees on compatiblity at all between any releases). Scott From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 19:45:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 807B516A41F for ; Wed, 9 Nov 2005 19:45:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 164E343D45 for ; Wed, 9 Nov 2005 19:45:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1315A1A3C29; Wed, 9 Nov 2005 11:45:57 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CFFA7514A3; Wed, 9 Nov 2005 14:45:55 -0500 (EST) Date: Wed, 9 Nov 2005 14:45:55 -0500 From: Kris Kennaway To: Rainer Duffner Message-ID: <20051109194555.GA44122@xor.obsecurity.org> References: <43723F49.9010109@ultra-secure.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <43723F49.9010109@ultra-secure.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 19:45:58 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 09, 2005 at 07:26:17PM +0100, Rainer Duffner wrote: > Hello, >=20 > this is on a dual 1.2 GHz Supermicro P3TDE6 board. >=20 > Sorry, I can't provide more details, just wanted to let you know. > I have little time, so I just removed the RAM. The machine is fine with= =20 > 1 or 2 GB RAM. Replace the defective remaining 2GB, then :-) Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDclHzWry0BWjoQKURAmGkAJ49cNKDC10ocGk/YPUhv1fYNNFX5ACg+5xN rcZpZfvjufBtZwty9ftyfH8= =G8sh -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 19:48:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48B0316A41F for ; Wed, 9 Nov 2005 19:48:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1905C43D45 for ; Wed, 9 Nov 2005 19:48:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA9JmSto007268; Wed, 9 Nov 2005 12:48:28 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43725294.2010905@samsco.org> Date: Wed, 09 Nov 2005 12:48:36 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rainer Duffner References: <43723F49.9010109@ultra-secure.de> In-Reply-To: <43723F49.9010109@ultra-secure.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 19:48:32 -0000 Rainer Duffner wrote: > Hello, > > this is on a dual 1.2 GHz Supermicro P3TDE6 board. > > Sorry, I can't provide more details, just wanted to let you know. > I have little time, so I just removed the RAM. The machine is fine with > 1 or 2 GB RAM. > > > cheers, > Rainer Can't help you without more details. I regularly run with 4-8GB of RAM without any problems whatsoever. Scott From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 20:02:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2E6916A41F for ; Wed, 9 Nov 2005 20:02:56 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC86043D46 for ; Wed, 9 Nov 2005 20:02:55 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 93704 invoked by uid 89); 9 Nov 2005 20:02:54 -0000 Received: by simscan 1.1.0 ppid: 93690, pid: 93700, t: 1.0921s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Nov 2005 20:02:53 -0000 Message-ID: <437255E4.8070002@ultra-secure.de> Date: Wed, 09 Nov 2005 21:02:44 +0100 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current References: <43723F49.9010109@ultra-secure.de> <20051109194555.GA44122@xor.obsecurity.org> In-Reply-To: <20051109194555.GA44122@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=7.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 20:02:56 -0000 Kris Kennaway wrote: >On Wed, Nov 09, 2005 at 07:26:17PM +0100, Rainer Duffner wrote: > > >>Hello, >> >>this is on a dual 1.2 GHz Supermicro P3TDE6 board. >> >>Sorry, I can't provide more details, just wanted to let you know. >>I have little time, so I just removed the RAM. The machine is fine with >>1 or 2 GB RAM. >> >> > >Replace the defective remaining 2GB, then :-) > > > > ;-) The server ran RedHat 7.2 before. With no problems. I should have mentioned we have about 8 of these monsters (they are 5 to 7 U and heavy) and they are all running RH7.2 and most have at least 3 GB RAM. Rainer From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 20:05:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEB1316A41F for ; Wed, 9 Nov 2005 20:05:31 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1171E43D45 for ; Wed, 9 Nov 2005 20:05:30 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 94061 invoked by uid 89); 9 Nov 2005 20:05:30 -0000 Received: by simscan 1.1.0 ppid: 94040, pid: 94057, t: 1.2391s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Nov 2005 20:05:28 -0000 Message-ID: <43725683.8080805@ultra-secure.de> Date: Wed, 09 Nov 2005 21:05:23 +0100 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <43723F49.9010109@ultra-secure.de> <43725294.2010905@samsco.org> In-Reply-To: <43725294.2010905@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=7.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 20:05:32 -0000 Scott Long wrote: > Rainer Duffner wrote: > >> Hello, >> >> this is on a dual 1.2 GHz Supermicro P3TDE6 board. >> >> Sorry, I can't provide more details, just wanted to let you know. >> I have little time, so I just removed the RAM. The machine is fine >> with 1 or 2 GB RAM. >> >> >> cheers, >> Rainer > > > Can't help you without more details. I regularly run with 4-8GB of RAM > without any problems whatsoever. It may only be this silly board. I've recently played with a 6.0 RC on a Dual Xeon 3.2 (Lindenhurst) and it worked. The machines are relatively old now - they are being re-purposed now, piece-by-piece. But RH7.2 seems to work with it. Rainer From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 20:05:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9744816A41F for ; Wed, 9 Nov 2005 20:05:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E21CF43D49 for ; Wed, 9 Nov 2005 20:05:56 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B66531A3C25; Wed, 9 Nov 2005 12:05:56 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 86DAA515DF; Wed, 9 Nov 2005 15:05:55 -0500 (EST) Date: Wed, 9 Nov 2005 15:05:55 -0500 From: Kris Kennaway To: Rainer Duffner Message-ID: <20051109200555.GA48012@xor.obsecurity.org> References: <43723F49.9010109@ultra-secure.de> <20051109194555.GA44122@xor.obsecurity.org> <437255E4.8070002@ultra-secure.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <437255E4.8070002@ultra-secure.de> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 20:05:57 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 09, 2005 at 09:02:44PM +0100, Rainer Duffner wrote: > Kris Kennaway wrote: >=20 > >On Wed, Nov 09, 2005 at 07:26:17PM +0100, Rainer Duffner wrote: > >=20 > > > >>Hello, > >> > >>this is on a dual 1.2 GHz Supermicro P3TDE6 board. > >> > >>Sorry, I can't provide more details, just wanted to let you know. > >>I have little time, so I just removed the RAM. The machine is fine with= =20 > >>1 or 2 GB RAM. > >> =20 > >> > > > >Replace the defective remaining 2GB, then :-) > > > > > >=20 > > >=20 > ;-) > The server ran RedHat 7.2 before. With no problems. > I should have mentioned we have about 8 of these monsters (they are 5 to= =20 > 7 U and heavy) and they are all running RH7.2 and most have at least 3=20 > GB RAM. As Scott said, we need some details then. I run FreeBSD 6.0 on many systems with >2GB of RAM (some up to 24GB) without problems. Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDclaiWry0BWjoQKURAu/hAKD0nCxQPblt5B7bfDD5CpsaDcmX1ACgrDqN 9u8RqbW6dQtoFtzMW0RaNpM= =+enz -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 21:06:32 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED4016A422 for ; Wed, 9 Nov 2005 21:06:32 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAFB543D45 for ; Wed, 9 Nov 2005 21:06:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EBB3946BDC; Wed, 9 Nov 2005 16:06:28 -0500 (EST) Date: Wed, 9 Nov 2005 21:06:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mark Linimon In-Reply-To: <20051109200458.GA26742@soaustin.net> Message-ID: <20051109210246.Y33260@fledge.watson.org> References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109093920.GA45506@samodelkin.net> <20051109110903.583bb72d.lists@yazzy.org> <20051109121720.M39365@fledge.watson.org> <20051109200458.GA26742@soaustin.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcin Jessa , current@freebsd.org, Max Khon Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 21:06:32 -0000 On Wed, 9 Nov 2005, Mark Linimon wrote: > On Wed, Nov 09, 2005 at 12:20:14PM +0000, Robert Watson wrote: >> My hope is that in the next year or so, things will settle down >> significantly as we begin to flush the last of the non-MPSAFE drivers >> from the system, and reach a point where all device drivers can use >> consistent synchronization. > > If we are working towards that, I'd like to see someone contact the > suppliers of the binary-only drivers and tell them that's where we're > heading. IMHO we are starting to win back some 'mind-share' out there > in the real world with 6.0 and we should build on that momentum. I think the first step is to figure out what we're doing. In the past, we've tried to offer relative API/ABI stability across minor releases for two classes of device drivers: - Network interface device drivers - Storage device drivers However, we've not made a formal effort to decide what APIs are "safe" for device driver vendors to use, and only in the 5/6 time frame have we attempted to start hardening the APIs so as to make it possible to keep evolving the implementation in a branch without breaking device drivers. Some work needs to be done up front to survey what APIs and ABIs device drivers currently use, or use indirectly -- things like which data structures they depend on for stability (offset of fields in struct thread?), which symbols they depend on, what structures they embed (meaning we need to preserve size, not just layout) in the stack or their own data structures. In 6.x, with ifnet no longer being embedded in device driver data structures, we've improved quite a bit. In the developer summit session on the topic, I'm proposing we identify depenendencies of network device drivers, and then discuss where to harden, where to hide, and so on. We won't get it entirely right the first time, but I think a bit of investigation and a bit of cleanup will go a long way. Fortunately, we have a pretty good sampling of network device drivers in our tree already to look at. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 21:23:34 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 055DB16A41F for ; Wed, 9 Nov 2005 21:23:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E15643D48 for ; Wed, 9 Nov 2005 21:23:33 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 98B295F89; Wed, 9 Nov 2005 16:23:32 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57326-04; Wed, 9 Nov 2005 16:23:31 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 4AAFC5F7C; Wed, 9 Nov 2005 16:23:31 -0500 (EST) In-Reply-To: <437246C5.2030607@elischer.org> References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> <20051109093552.3082c51b.lists@yazzy.org> <437246C5.2030607@elischer.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A496451-166E-46F1-8363-19F117156FEE@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 9 Nov 2005 16:23:28 -0500 To: Julian Elischer X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: Marcin Jessa , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 21:23:34 -0000 On Nov 9, 2005, at 1:58 PM, Julian Elischer wrote: > Marcin Jessa wrote: [ ... ] >> My idea is to create an API for binary vendor drivers to make it >> easier for hardware vendors to create FreeBSD drivers the same way >> they can do for Windows or Mac OS X. > > well, you could port the Darwin driver interface in the form of a > shim, or > extend "project evil" to cover more kinds of drivers.. An interesting thought, although the IOKit uses an embedded C++ subset rather than plain C [1]. For those who aren't familiar with it, the Darwin kernel API for drivers, variously called the IOKit or DriverKit, is documented here: http://developer.apple.com/documentation/DeviceDrivers/ ...and the "Fundamentals" document is an interesting read: "First, neither the Mac OS 9 driver model nor the FreeBSD driver model offers a set of features rich enough to meet the needs of Mac OS X. The Mac OS X kernel is significantly more advanced than its Mac OS precursors; it handles memory protection, preemptive multitasking, multiprocessing, and other features not present in previous versions of Mac OS. Although FreeBSD is capable of handling these features, the BSD model does not offer other features expected in a modern operating system, including automatic configuration, driver stacking, power management, and dynamic loading of devices." In truth, FreeBSD does have reasonable support for PnP autoconfig and dynamic loading of device drivers, and FreeBSD does have a decent C- based object system with introspection in , although that doesn't seem to be fully taken advantage of in places where it could be, except perhaps in the sound and UART drivers. Most other FreeBSD drivers are "flat" and have a fair amount of code duplication, rather than using OO inheritance so that your fxp or dc driver inherits from a common NIC abstraction (Apple's IONetworkController -> IOEthernetController -> _device_). Apple has found that using inheritance is a big win for them: "In addition, code reusability decreases the memory footprint of drivers; drivers ported from Mac OS 9, for example, have been up to 75% smaller in Mac OS X." Of course, it's easier to say such things then to write the code, but Apple has achieved pretty good results from the IOKit. -- -Chuck [1]: http://www.caravan.net/ec2plus/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 21:38:17 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1462E16A41F for ; Wed, 9 Nov 2005 21:38:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F9A43D53 for ; Wed, 9 Nov 2005 21:38:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id C306B5F4A; Wed, 9 Nov 2005 16:38:09 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34875-10; Wed, 9 Nov 2005 16:38:08 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id CBD585F38; Wed, 9 Nov 2005 16:38:08 -0500 (EST) In-Reply-To: <43724D29.906@samsco.org> References: <20051108232855.2d1b7df5.lists@yazzy.org> <437145DF.2040508@samsco.org> <20051109093552.3082c51b.lists@yazzy.org> <43724D29.906@samsco.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Wed, 9 Nov 2005 16:38:07 -0500 To: Scott Long X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 21:38:17 -0000 On Nov 9, 2005, at 2:25 PM, Scott Long wrote: > Where this breaks down is in moving from 6.x to 7.0. We make no > guarantees there for binary or source compatiblity. Apple is =20 > trying to > address with problem with KPI's. There are obvious advantages to =20 > this, > but the cost is quite high. It took them a number of years to go > through the system and essentially re-write most of it. And it's =20 > still > really only a theory; porting from 10.3 to 10.4 is hard because you > have to adopt the KPIs in your code, and no one has seen 10.5 yet to > decide if the KPI is really the same there. That's not entirely true: I've been able to use third-party USB =20 drivers from 10.2 and 10.3 under 10.4. You do not have to adopt KPIs =20= if your 10.3 driver code was using pure IOKit mechanisms, because =20 Apple has provided backwards compatibility for such older driver =20 binaries. =46rom (long link, may get split): http://developer.apple.com/documentation/Darwin/Conceptual/=20 KEXTConcept/KEXTConceptDependencies/kext_dependencies.html "Declare dependencies on the kernel subcomponents available in =20 earlier versions of Mac OS X. This method provides backward =20 compatibility for pure I/O Kit KEXTs, but some Mach and BSD symbols =20 are no longer available. When you use this method, use the version of =20= the kernel subcomponent that corresponds to the earliest version of =20 Mac OS X you need to support (see the tables in =93Declaring =20 Dependencies on Kernel Subcomponents=94 for these values). This method is suitable for pure I/O Kit KEXTs that must run in =20 versions of Mac OS X prior to Mac OS X v10.4." Apple's included version tables for com.apple.kernel.libkern, =20 com.apple.kernel.iokit, and so forth from MacOS X 10.0 onwards later =20 on that page. --=20 -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 22:18:54 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2C1116A421 for ; Wed, 9 Nov 2005 22:18:54 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93FE43D49 for ; Wed, 9 Nov 2005 22:18:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 83C23BC66; Wed, 9 Nov 2005 22:18:44 +0000 (UTC) To: Charles Swiger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Nov 2005 16:23:28 EST." <1A496451-166E-46F1-8363-19F117156FEE@mac.com> Date: Wed, 09 Nov 2005 23:18:43 +0100 Message-ID: <1566.1131574723@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Marcin Jessa , Julian Elischer , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 22:18:54 -0000 In message <1A496451-166E-46F1-8363-19F117156FEE@mac.com>, Charles Swiger write s: >Apple has found that using inheritance is a big win for them: "In >addition, code reusability decreases the memory footprint of drivers; >drivers ported from Mac OS 9, for example, have been up to 75% >smaller in Mac OS X." Of course, it's easier to say such things then >to write the code, but Apple has achieved pretty good results from >the IOKit. Apple also has significantly better control over the hardware they have to write drivers for. That said, there is a lot of stuff which could be improved in our APIs. And I wouldn't mind getting a "C with classes" language with a couple of domain-specific extensions in the bargain. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 00:39:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C496016A41F for ; Thu, 10 Nov 2005 00:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4687C43D55 for ; Thu, 10 Nov 2005 00:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 9A8615F7E; Wed, 9 Nov 2005 19:39:12 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24607-07; Wed, 9 Nov 2005 19:39:11 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 5239B5D82; Wed, 9 Nov 2005 19:39:11 -0500 (EST) In-Reply-To: <1566.1131574723@critter.freebsd.dk> References: <1566.1131574723@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 9 Nov 2005 19:39:10 -0500 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 00:39:14 -0000 On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote: >> Apple has found that using inheritance is a big win for them: "In >> addition, code reusability decreases the memory footprint of drivers; >> drivers ported from Mac OS 9, for example, have been up to 75% >> smaller in Mac OS X." Of course, it's easier to say such things then >> to write the code, but Apple has achieved pretty good results from >> the IOKit. > > Apple also has significantly better control over the hardware > they have to write drivers for. Over their own hardware, agreed. However, there are a number of third-party hardware devices being used with Macs which Apple has no control over, things like GPS receivers using USB-to-serial converters, etc. Retaining backwards compatibility with older software, including older kernel modules (so long as they follow the rules), seems to be a very high priority for Apple, and they've done a fair-to-decent job of it. [ They've had some problems, too, such as VPN software breaking from 10.3 -> 10.4. ] > That said, there is a lot of stuff which could be improved in our > APIs. And I wouldn't mind getting a "C with classes" language with > a couple > of domain-specific extensions in the bargain. I'm not strongly advocating the use of C++ in the kernel, but Apple is using g++ to build their kernels, so I'd imagine that FreeBSD could utilize the same embedded C++ dialect in our kernels if people wanted to do so. The things that leapt out at me in comparing the FreeBSD APIs and IOKit were: 1) the notion of a system-wide driver registry, which could be obtained easily from the existing code in sys/bus.h & kern/subr_bus.c which keeps track of this: typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; [ devclass_get_devices() is close but not quite the same thing... ] 2) the "work loop" abstraction (long link, again): http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ IOKitFundamentals/HandlingEvents/chapter_8_section_2.html Programming using callbacks or continuations, having to serialize access to driver data structures, etc is one of the most difficult areas to deal with, and race conditions and so forth are a common source of evil, tricky, hard-to-reproduce bugs. There isn't a free lunch, the kernel has got to deal with such things, but having an abstraction like this would probably help make the lives of people writing drivers easier. [1] 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide an abstraction for managing virtual memory mappings and representing DMA or PIO activity (ie, building a scatter/gather list appropriate for a particular NIC or RAID controller's DMA engine): http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ IOKitFundamentals/DataMgmt/chapter_9_section_5.html -- -Chuck [1]: One _single_ abstraction, that is, rather than having lots of variants of similar code scattered hither and yon. From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 01:14:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D00F16A41F for ; Thu, 10 Nov 2005 01:14:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBB5743D45 for ; Thu, 10 Nov 2005 01:13:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAA1DqqS027273; Wed, 9 Nov 2005 18:13:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43729ED9.9050204@samsco.org> Date: Wed, 09 Nov 2005 18:14:01 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Swiger References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> In-Reply-To: <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 01:14:00 -0000 Charles Swiger wrote: > On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote: > >>> Apple has found that using inheritance is a big win for them: "In >>> addition, code reusability decreases the memory footprint of drivers; >>> drivers ported from Mac OS 9, for example, have been up to 75% >>> smaller in Mac OS X." Of course, it's easier to say such things then >>> to write the code, but Apple has achieved pretty good results from >>> the IOKit. >> >> >> Apple also has significantly better control over the hardware >> they have to write drivers for. > > > Over their own hardware, agreed. However, there are a number of > third-party hardware devices being used with Macs which Apple has no > control over, things like GPS receivers using USB-to-serial converters, > etc. > > Retaining backwards compatibility with older software, including older > kernel modules (so long as they follow the rules), seems to be a very > high priority for Apple, and they've done a fair-to-decent job of it. > > [ They've had some problems, too, such as VPN software breaking from > 10.3 -> 10.4. ] > >> That said, there is a lot of stuff which could be improved in our >> APIs. And I wouldn't mind getting a "C with classes" language with a >> couple >> of domain-specific extensions in the bargain. > I have a fair amount of very close experience with the OSX kernel. See my comment below: > > I'm not strongly advocating the use of C++ in the kernel, but Apple is > using g++ to build their kernels, so I'd imagine that FreeBSD could > utilize the same embedded C++ dialect in our kernels if people wanted > to do so. The things that leapt out at me in comparing the FreeBSD > APIs and IOKit were: A cut down version of C++ is used for IOKit, it is not used for the whole kernel. The large majority of the kernel is written in C, not C++. Not all kernel modules are hardware device drivers, neither in OSX or in FreeBSD. GEOM modules, filesystems, and netgraph modules are all valid examples of pseudo drivers that benefit from a stable API but do not represent hardware devices. So IOKit is not the cure-all API. > > 1) the notion of a system-wide driver registry, which could be obtained > easily from the existing code in sys/bus.h & kern/subr_bus.c which > keeps track of this: > > typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; > > [ devclass_get_devices() is close but not quite the same thing... ] > There is already a module registry. It's used to know when to reject loading KLDs that contain modules that are already in the system. This works for both device drivers and pseudo drivers. > 2) the "work loop" abstraction (long link, again): > > http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ > IOKitFundamentals/HandlingEvents/chapter_8_section_2.html > > Programming using callbacks or continuations, having to serialize > access to driver data structures, etc is one of the most difficult > areas to deal with, and race conditions and so forth are a common > source of evil, tricky, hard-to-reproduce bugs. There isn't a free > lunch, the kernel has got to deal with such things, but having an > abstraction like this would probably help make the lives of people > writing drivers easier. [1] I've written an IOKit driver for high performance hardware. I'm not convinced that the work loop paradigm is any more efficient than locking. Apple advocates it because it is indeed easier to program to and takes less to explain than using the different locking primitives. Remember that the target audience for much of the Apple documentation is people who have never programmed in a Unix kernel before, be they coming from Windows or coming from OS9. In fact, the Apple docs go out of their way to discourage you from writing kernel modules entirely. > > 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide an > abstraction for managing virtual memory mappings and representing DMA > or PIO activity (ie, building a scatter/gather list appropriate for a > particular NIC or RAID controller's DMA engine): > > http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ > IOKitFundamentals/DataMgmt/chapter_9_section_5.html > There is already a well established and stable API for doing DMA in FreeBSD. Just about every driver in the kernel uses it. Why change? There are good ideas in the IOKit that I've advocated for FreeBSD in the past (interrupt filters, for example), and the object oriented approach there is certainly interesting, but I don't see it as a cure all to stability or ease. Scott From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 02:22:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA1FB16A41F for ; Thu, 10 Nov 2005 02:22:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F7AB43D46 for ; Thu, 10 Nov 2005 02:22:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 09 Nov 2005 18:22:15 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <4372AED7.9000403@elischer.org> Date: Wed, 09 Nov 2005 18:22:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> In-Reply-To: <43729ED9.9050204@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 02:22:15 -0000 Scott Long wrote: > Charles Swiger wrote: > >> On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote: >> >>>> Apple has found that using inheritance is a big win for them: "In >>>> addition, code reusability decreases the memory footprint of drivers; >>>> drivers ported from Mac OS 9, for example, have been up to 75% >>>> smaller in Mac OS X." Of course, it's easier to say such things then >>>> to write the code, but Apple has achieved pretty good results from >>>> the IOKit. >>> >>> >>> >>> Apple also has significantly better control over the hardware >>> they have to write drivers for. >> >> >> >> Over their own hardware, agreed. However, there are a number of >> third-party hardware devices being used with Macs which Apple has no >> control over, things like GPS receivers using USB-to-serial >> converters, etc. >> >> Retaining backwards compatibility with older software, including >> older kernel modules (so long as they follow the rules), seems to be >> a very high priority for Apple, and they've done a fair-to-decent >> job of it. >> >> [ They've had some problems, too, such as VPN software breaking from >> 10.3 -> 10.4. ] >> >>> That said, there is a lot of stuff which could be improved in our >>> APIs. And I wouldn't mind getting a "C with classes" language with >>> a couple >>> of domain-specific extensions in the bargain. >> >> > > I have a fair amount of very close experience with the OSX kernel. See > my comment below: > >> >> I'm not strongly advocating the use of C++ in the kernel, but Apple >> is using g++ to build their kernels, so I'd imagine that FreeBSD >> could utilize the same embedded C++ dialect in our kernels if people >> wanted to do so. The things that leapt out at me in comparing the >> FreeBSD APIs and IOKit were: > > > A cut down version of C++ is used for IOKit, it is not used for the > whole kernel. The large majority of the kernel is written in C, not > C++. Not all kernel modules are hardware device drivers, neither in > OSX or in FreeBSD. GEOM modules, filesystems, and netgraph modules are > all valid examples of pseudo drivers that benefit from a stable API but > do not represent hardware devices. So IOKit is not the cure-all API. > >> >> 1) the notion of a system-wide driver registry, which could be >> obtained easily from the existing code in sys/bus.h & >> kern/subr_bus.c which keeps track of this: >> >> typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; >> >> [ devclass_get_devices() is close but not quite the same thing... ] >> > > There is already a module registry. It's used to know when to reject > loading KLDs that contain modules that are already in the system. This > works for both device drivers and pseudo drivers. > >> 2) the "work loop" abstraction (long link, again): >> >> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >> IOKitFundamentals/HandlingEvents/chapter_8_section_2.html >> >> Programming using callbacks or continuations, having to serialize >> access to driver data structures, etc is one of the most difficult >> areas to deal with, and race conditions and so forth are a common >> source of evil, tricky, hard-to-reproduce bugs. There isn't a free >> lunch, the kernel has got to deal with such things, but having an >> abstraction like this would probably help make the lives of people >> writing drivers easier. [1] > > > I've written an IOKit driver for high performance hardware. I'm not > convinced that the work loop paradigm is any more efficient than > locking. Apple advocates it because it is indeed easier to program to > and takes less to explain than using the different locking primitives. > Remember that the target audience for much of the Apple documentation is > people who have never programmed in a Unix kernel before, be they coming > from Windows or coming from OS9. In fact, the Apple docs go out of > their way to discourage you from writing kernel modules entirely. > >> >> 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide >> an abstraction for managing virtual memory mappings and representing >> DMA or PIO activity (ie, building a scatter/gather list appropriate >> for a particular NIC or RAID controller's DMA engine): >> >> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >> IOKitFundamentals/DataMgmt/chapter_9_section_5.html >> > > There is already a well established and stable API for doing DMA in > FreeBSD. Just about every driver in the kernel uses it. Why change? > > There are good ideas in the IOKit that I've advocated for FreeBSD in the > past (interrupt filters, for example), and the object oriented approach > there is certainly interesting, but I don't see it as a cure all to > stability or ease. but if we could implement it we could run apple drivers.... (when they move to x86) > > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 02:41:37 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F5D16A41F for ; Thu, 10 Nov 2005 02:41:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 156AA43D45 for ; Thu, 10 Nov 2005 02:41:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAA2fSax027689; Wed, 9 Nov 2005 19:41:28 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4372B360.50203@samsco.org> Date: Wed, 09 Nov 2005 19:41:36 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> <4372AED7.9000403@elischer.org> In-Reply-To: <4372AED7.9000403@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 02:41:37 -0000 Julian Elischer wrote: > Scott Long wrote: > >> Charles Swiger wrote: >> >>> On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote: >>> >>>>> Apple has found that using inheritance is a big win for them: "In >>>>> addition, code reusability decreases the memory footprint of drivers; >>>>> drivers ported from Mac OS 9, for example, have been up to 75% >>>>> smaller in Mac OS X." Of course, it's easier to say such things then >>>>> to write the code, but Apple has achieved pretty good results from >>>>> the IOKit. >>>> >>>> >>>> >>>> >>>> Apple also has significantly better control over the hardware >>>> they have to write drivers for. >>> >>> >>> >>> >>> Over their own hardware, agreed. However, there are a number of >>> third-party hardware devices being used with Macs which Apple has no >>> control over, things like GPS receivers using USB-to-serial >>> converters, etc. >>> >>> Retaining backwards compatibility with older software, including >>> older kernel modules (so long as they follow the rules), seems to be >>> a very high priority for Apple, and they've done a fair-to-decent >>> job of it. >>> >>> [ They've had some problems, too, such as VPN software breaking from >>> 10.3 -> 10.4. ] >>> >>>> That said, there is a lot of stuff which could be improved in our >>>> APIs. And I wouldn't mind getting a "C with classes" language with >>>> a couple >>>> of domain-specific extensions in the bargain. >>> >>> >>> >> >> I have a fair amount of very close experience with the OSX kernel. See >> my comment below: >> >>> >>> I'm not strongly advocating the use of C++ in the kernel, but Apple >>> is using g++ to build their kernels, so I'd imagine that FreeBSD >>> could utilize the same embedded C++ dialect in our kernels if people >>> wanted to do so. The things that leapt out at me in comparing the >>> FreeBSD APIs and IOKit were: >> >> >> >> A cut down version of C++ is used for IOKit, it is not used for the >> whole kernel. The large majority of the kernel is written in C, not >> C++. Not all kernel modules are hardware device drivers, neither in >> OSX or in FreeBSD. GEOM modules, filesystems, and netgraph modules are >> all valid examples of pseudo drivers that benefit from a stable API but >> do not represent hardware devices. So IOKit is not the cure-all API. >> >>> >>> 1) the notion of a system-wide driver registry, which could be >>> obtained easily from the existing code in sys/bus.h & >>> kern/subr_bus.c which keeps track of this: >>> >>> typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; >>> >>> [ devclass_get_devices() is close but not quite the same thing... ] >>> >> >> There is already a module registry. It's used to know when to reject >> loading KLDs that contain modules that are already in the system. This >> works for both device drivers and pseudo drivers. >> >>> 2) the "work loop" abstraction (long link, again): >>> >>> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >>> IOKitFundamentals/HandlingEvents/chapter_8_section_2.html >>> >>> Programming using callbacks or continuations, having to serialize >>> access to driver data structures, etc is one of the most difficult >>> areas to deal with, and race conditions and so forth are a common >>> source of evil, tricky, hard-to-reproduce bugs. There isn't a free >>> lunch, the kernel has got to deal with such things, but having an >>> abstraction like this would probably help make the lives of people >>> writing drivers easier. [1] >> >> >> >> I've written an IOKit driver for high performance hardware. I'm not >> convinced that the work loop paradigm is any more efficient than >> locking. Apple advocates it because it is indeed easier to program to >> and takes less to explain than using the different locking primitives. >> Remember that the target audience for much of the Apple documentation is >> people who have never programmed in a Unix kernel before, be they coming >> from Windows or coming from OS9. In fact, the Apple docs go out of >> their way to discourage you from writing kernel modules entirely. >> >>> >>> 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide >>> an abstraction for managing virtual memory mappings and representing >>> DMA or PIO activity (ie, building a scatter/gather list appropriate >>> for a particular NIC or RAID controller's DMA engine): >>> >>> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >>> IOKitFundamentals/DataMgmt/chapter_9_section_5.html >>> >> >> There is already a well established and stable API for doing DMA in >> FreeBSD. Just about every driver in the kernel uses it. Why change? >> >> There are good ideas in the IOKit that I've advocated for FreeBSD in the >> past (interrupt filters, for example), and the object oriented approach >> there is certainly interesting, but I don't see it as a cure all to >> stability or ease. > > > but if we could implement it we could run apple drivers.... > (when they move to x86) > No, we can't, unless we emulate the rest of the kernel API in OSX. IOKit doesn't describe the entire kernel API. Think of it as 'newbus done right' and nothing more. The rest of the kernel interfaces are up for grabs. Some look and act like their BSD counterparts, some do not. Scott From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:01:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E56B116A439; Thu, 10 Nov 2005 03:01:08 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A3A943D46; Thu, 10 Nov 2005 03:01:07 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id 95B1C63D2; Thu, 10 Nov 2005 12:02:27 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88636-08; Thu, 10 Nov 2005 12:02:19 +0900 (JST) Received: from flora220.uki-uki.net (unknown [209.52.153.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 86E3F63CB; Thu, 10 Nov 2005 12:02:17 +0900 (JST) Date: Wed, 09 Nov 2005 18:59:45 -0800 Message-ID: From: SUZUKI Shinsuke To: jr@opal.com X-cite: xcite 1.33 In-Reply-To: <20051110024941.GA987@linwhf.opal.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: current@freebsd.org, sean@mcneil.com, ume@freebsd.org Subject: TCPv6 unexpectedly dropped by PF / Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 03:01:09 -0000 #I changed the ML title, since it's a different problem from Sean's #one. >>>>> On Wed, 9 Nov 2005 21:49:41 -0500 >>>>> jr@opal.com("J.R. Oldroyd") said: > However TCP traffic is broke, for example, when I try to telnet to the POP3 > server here, I observe that pf is blocking the server's response packets with > this error: > > # telnet 2001:5c0:8fff:fffe::553 110 > Trying 2001:5c0:8fff:fffe::553... > ^C > > from pflog: > 21:45:03.080452 rule 0/0(match): block in on gif0: 2001:5c0:8fff:fffe::553.110 > 2001:5c0:8fff:fffe::553.56716: tcp 36 [bad hdr length 8 - too short, < 20] > > This did not happen on earlier 6.0-current. Could you please tell me the specific PF rule which caused the above match? Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:14:22 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4493A16A41F; Thu, 10 Nov 2005 03:14:22 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id C586343D46; Thu, 10 Nov 2005 03:14:21 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id 28F6D63CB; Thu, 10 Nov 2005 12:15:41 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88734-09; Thu, 10 Nov 2005 12:15:32 +0900 (JST) Received: from flora220.uki-uki.net (unknown [209.52.153.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 3A8A563D2; Thu, 10 Nov 2005 12:15:31 +0900 (JST) Date: Wed, 09 Nov 2005 19:12:58 -0800 Message-ID: From: SUZUKI Shinsuke To: sean@mcneil.com X-cite: xcite 1.33 In-Reply-To: <1131591746.24065.3.camel@triton.mcneil.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> <1131591746.24065.3.camel@triton.mcneil.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: jr@opal.com, ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 03:14:22 -0000 Hi, >>>>> On Wed, 09 Nov 2005 19:02:26 -0800 >>>>> sean@mcneil.com(Sean McNeil) said: > Oh Boy! This is very interesting. I took a look at my ipfw show during > a ping6 and see the problem. The revpath is messed up. I took out my > rule: > > add deny all from any to any not verrevpath in via dc0 > > and ping6 now works. > > Thanks for the clue! great! I'll check it from this point of view. Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:15:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4475816A42D for ; Thu, 10 Nov 2005 03:15:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA8F43D67 for ; Thu, 10 Nov 2005 03:15:14 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 085E75F52; Wed, 9 Nov 2005 22:15:14 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93902-09; Wed, 9 Nov 2005 22:15:12 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 991C75D8C; Wed, 9 Nov 2005 22:15:11 -0500 (EST) Message-ID: <4372BB3E.5030304@mac.com> Date: Wed, 09 Nov 2005 22:15:10 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> In-Reply-To: <43729ED9.9050204@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 03:15:16 -0000 Scott Long wrote: > Charles Swiger wrote: [ ... ] > I have a fair amount of very close experience with the OSX kernel. See > my comment below: I'd say that you have some experience with the FreeBSD kernel, too. :-) >> I'm not strongly advocating the use of C++ in the kernel, but Apple >> is using g++ to build their kernels, so I'd imagine that FreeBSD >> could utilize the same embedded C++ dialect in our kernels if people >> wanted to do so. The things that leapt out at me in comparing the >> FreeBSD APIs and IOKit were: > > A cut down version of C++ is used for IOKit, it is not used for the > whole kernel. The large majority of the kernel is written in C, not > C++. Agreed. > Not all kernel modules are hardware device drivers, neither in > OSX or in FreeBSD. GEOM modules, filesystems, and netgraph modules are > all valid examples of pseudo drivers that benefit from a stable API but > do not represent hardware devices. So IOKit is not the cure-all API. Goodness, no. In some ways, I actually like FreeBSD's C implementation of device_t's using kobj's quite a bit compared to C++ code in the IOKit, and some driver families (sound in particular) seem to take advantage of inheritence more than other drivers do. The IOKit has some C++-related blemishes like: 3-pan% tail /System/Library/Frameworks/IOKit.framework/Versions/A/Headers/network/IONetworkController.h OSMetaClassDeclareReservedUnused( IONetworkController, 28); OSMetaClassDeclareReservedUnused( IONetworkController, 29); OSMetaClassDeclareReservedUnused( IONetworkController, 30); OSMetaClassDeclareReservedUnused( IONetworkController, 31); }; #endif /* defined(KERNEL) && defined(__cplusplus) */ #endif /* !_IONETWORKCONTROLLER_H */ ...reserving 32 slots and keeping a pointer variable to an undefined struct (*_unused) handy just in case due to the fragile base class issue. >> 1) the notion of a system-wide driver registry, which could be >> obtained easily from the existing code in sys/bus.h & kern/subr_bus.c >> which keeps track of this: >> >> typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; >> >> [ devclass_get_devices() is close but not quite the same thing... ] > > There is already a module registry. It's used to know when to reject > loading KLDs that contain modules that are already in the system. This > works for both device drivers and pseudo drivers. True, but a list of modules was not quite was I was looking for. >> 2) the "work loop" abstraction (long link, again): >> >> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >> IOKitFundamentals/HandlingEvents/chapter_8_section_2.html >> >> Programming using callbacks or continuations, having to serialize >> access to driver data structures, etc is one of the most difficult >> areas to deal with, and race conditions and so forth are a common >> source of evil, tricky, hard-to-reproduce bugs. There isn't a free >> lunch, the kernel has got to deal with such things, but having an >> abstraction like this would probably help make the lives of people >> writing drivers easier. [1] > > I've written an IOKit driver for high performance hardware. I'm not > convinced that the work loop paradigm is any more efficient than > locking. Apple advocates it because it is indeed easier to program to > and takes less to explain than using the different locking primitives. The IOKit provides relatively fine-grain mutex locking (on the class or instance level of driver objects) and supports re-entrancy: "An IOWorkLoop object (or simply, a work loop) is primarily a gating mechanism that ensures single-threaded access to the data structures used by hardware. For some event contexts, a work loop is also a thread. In essence, a work loop is a mutually exclusive (mutex) lock associated with a thread." ...while providing a API (or KPI) which lets the developer code as if he or she had a single worker thread, even though underneath, the system may be scheduling many worker threads amoungst the available CPUs and/or event sources. Certainly that's better (more efficient) than contending over the GIANT lock. > Remember that the target audience for much of the Apple documentation is > people who have never programmed in a Unix kernel before, be they coming > from Windows or coming from OS9. In fact, the Apple docs go out of > their way to discourage you from writing kernel modules entirely. Sure-- don't you agree that anything which can be done in userland, generally ought to be done there? Apple has to contend with developers who are looking to hook into the vertical blanking handler for screensavers and clock programs and who knows what else, just like they did in OS 9. Discouraging such things from going into the kernel is a good idea. Also remember that Mach is closer to being a microkernel than the other BSD kernels are, and the philosophy is showing in the design. That doesn't mean it's always the best approach, but Mach feels more consistent to me. >> 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide >> an abstraction for managing virtual memory mappings and representing >> DMA or PIO activity (ie, building a scatter/gather list appropriate >> for a particular NIC or RAID controller's DMA engine): >> >> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >> IOKitFundamentals/DataMgmt/chapter_9_section_5.html > > There is already a well established and stable API for doing DMA in > FreeBSD. Just about every driver in the kernel uses it. Why change? You mean isa_dmacascade(), isa_dma_acquire(), isa_dmainit() and bus_dma_*...? Eww. The forces of entropy are winning the fight to keep the ISA bus and DMA bounce buffers which must be less than 64K around forever, even on hardware which doesn't have such limitations. :-) > There are good ideas in the IOKit that I've advocated for FreeBSD in the > past (interrupt filters, for example), and the object oriented approach > there is certainly interesting, but I don't see it as a cure all to > stability or ease. The IOKit isn't a cure-all, nor is an OO viewpoint always the best approach. There isn't too much difference between inheriting the right behavior and having stuff like this in every driver: static device_method_t mypci_methods[] = { /* Device interface */ DEVMETHOD(device_probe, mypci_probe), DEVMETHOD(device_attach, mypci_attach), DEVMETHOD(device_detach, mypci_detach), DEVMETHOD(device_shutdown, mypci_shutdown), DEVMETHOD(device_suspend, mypci_suspend), DEVMETHOD(device_resume, mypci_resume), { 0, 0 } }; On the other hand, using inheritence for drivers seems to work pretty well in practice, and the notion of encapsulation seems to help Darwin avoid running into nearly as many lock-order reversals and layering violations. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:39:56 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5542216A41F for ; Thu, 10 Nov 2005 03:39:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8449543D48 for ; Thu, 10 Nov 2005 03:39:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAA3dr7F028031; Wed, 9 Nov 2005 20:39:53 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4372C112.5000105@samsco.org> Date: Wed, 09 Nov 2005 20:40:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> <4372BB3E.5030304@mac.com> In-Reply-To: <4372BB3E.5030304@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 03:39:56 -0000 Chuck Swiger wrote: > Scott Long wrote: > >> Charles Swiger wrote: > > [ ... ] > >> I have a fair amount of very close experience with the OSX kernel. See >> my comment below: > > > I'd say that you have some experience with the FreeBSD kernel, too. :-) > >>> I'm not strongly advocating the use of C++ in the kernel, but Apple >>> is using g++ to build their kernels, so I'd imagine that FreeBSD >>> could utilize the same embedded C++ dialect in our kernels if people >>> wanted to do so. The things that leapt out at me in comparing the >>> FreeBSD APIs and IOKit were: >> >> >> A cut down version of C++ is used for IOKit, it is not used for the >> whole kernel. The large majority of the kernel is written in C, not >> C++. > > > Agreed. > >> Not all kernel modules are hardware device drivers, neither in >> OSX or in FreeBSD. GEOM modules, filesystems, and netgraph modules are >> all valid examples of pseudo drivers that benefit from a stable API but >> do not represent hardware devices. So IOKit is not the cure-all API. > > > Goodness, no. In some ways, I actually like FreeBSD's C implementation > of device_t's using kobj's quite a bit compared to C++ code in the > IOKit, and some driver families (sound in particular) seem to take > advantage of inheritence more than other drivers do. > > The IOKit has some C++-related blemishes like: > > 3-pan% tail > /System/Library/Frameworks/IOKit.framework/Versions/A/Headers/network/IONetworkController.h > > OSMetaClassDeclareReservedUnused( IONetworkController, 28); > OSMetaClassDeclareReservedUnused( IONetworkController, 29); > OSMetaClassDeclareReservedUnused( IONetworkController, 30); > OSMetaClassDeclareReservedUnused( IONetworkController, 31); > }; > > #endif /* defined(KERNEL) && defined(__cplusplus) */ > > #endif /* !_IONETWORKCONTROLLER_H */ > > ...reserving 32 slots and keeping a pointer variable to an undefined > struct (*_unused) handy just in case due to the fragile base class issue. > >>> 1) the notion of a system-wide driver registry, which could be >>> obtained easily from the existing code in sys/bus.h & >>> kern/subr_bus.c which keeps track of this: >>> >>> typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; >>> >>> [ devclass_get_devices() is close but not quite the same thing... ] >> >> >> There is already a module registry. It's used to know when to reject >> loading KLDs that contain modules that are already in the system. This >> works for both device drivers and pseudo drivers. > > > True, but a list of modules was not quite was I was looking for. > >>> 2) the "work loop" abstraction (long link, again): >>> >>> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >>> IOKitFundamentals/HandlingEvents/chapter_8_section_2.html >>> >>> Programming using callbacks or continuations, having to serialize >>> access to driver data structures, etc is one of the most difficult >>> areas to deal with, and race conditions and so forth are a common >>> source of evil, tricky, hard-to-reproduce bugs. There isn't a free >>> lunch, the kernel has got to deal with such things, but having an >>> abstraction like this would probably help make the lives of people >>> writing drivers easier. [1] >> >> >> I've written an IOKit driver for high performance hardware. I'm not >> convinced that the work loop paradigm is any more efficient than >> locking. Apple advocates it because it is indeed easier to program to >> and takes less to explain than using the different locking primitives. > > > The IOKit provides relatively fine-grain mutex locking (on the class or > instance level of driver objects) and supports re-entrancy: > > "An IOWorkLoop object (or simply, a work loop) is primarily a gating > mechanism that ensures single-threaded access to the data structures > used by hardware. For some event contexts, a work loop is also a thread. > In essence, a work loop is a mutually exclusive (mutex) lock associated > with a thread." > > ...while providing a API (or KPI) which lets the developer code as if he > or she had a single worker thread, even though underneath, the system > may be scheduling many worker threads amoungst the available CPUs and/or > event sources. > > Certainly that's better (more efficient) than contending over the GIANT > lock. Condending over Giant is a thing of the past. Most of the major subsystems and drivers are out from under it. The few that are not are now separated enough that contention is extremely low. Studies are being done on this very topic right now, in fact, and the results are quite good. > >> Remember that the target audience for much of the Apple documentation is >> people who have never programmed in a Unix kernel before, be they coming >> from Windows or coming from OS9. In fact, the Apple docs go out of >> their way to discourage you from writing kernel modules entirely. > > > Sure-- don't you agree that anything which can be done in userland, > generally ought to be done there? Apple has to contend with developers > who are looking to hook into the vertical blanking handler for > screensavers and clock programs and who knows what else, just like they > did in OS 9. Discouraging such things from going into the kernel is a > good idea. > > Also remember that Mach is closer to being a microkernel than the other > BSD kernels are, and the philosophy is showing in the design. That > doesn't mean it's always the best approach, but Mach feels more > consistent to me. The use of Mach in OSX in a whole lot more limited that you might think. The three uses are the BSD+IOkit kernel, the window server, and the security server. The filesystems are still inside the BSD task, as are most drivers. The exception here is certain kinds of USB peripheral drivers. The USB hardware driver itself is still inside the kernel task. > >>> 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide >>> an abstraction for managing virtual memory mappings and representing >>> DMA or PIO activity (ie, building a scatter/gather list appropriate >>> for a particular NIC or RAID controller's DMA engine): >>> >>> http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ >>> IOKitFundamentals/DataMgmt/chapter_9_section_5.html >> >> >> There is already a well established and stable API for doing DMA in >> FreeBSD. Just about every driver in the kernel uses it. Why change? > > > You mean isa_dmacascade(), isa_dma_acquire(), isa_dmainit() and > bus_dma_*...? > > Eww. Uh, what? > > The forces of entropy are winning the fight to keep the ISA bus and DMA > bounce buffers which must be less than 64K around forever, even on > hardware which doesn't have such limitations. :-) Until the G5 was introduced, OSX never had to worry about making 32-bit DMA work on >4GB memory configurations, and it certainly never worried about ISA DMA. These are all still realities for i386 and amd64. There are a lot of common I/O controllers out there, including traditional ATA, that can't do 64-bit DMA and thus __require__ bounce buffers. Sparc64 requires that you program the IOMMU in order to do any DMA. Busdma makes all of this transparent. And as for the G5, it does h0h0 magic to make 32bit DMA work that is outside the scope of the IOMemory classes. So, I'm sure what you have against the existing APIs, but they work well for the FreeBSD environment. > >> There are good ideas in the IOKit that I've advocated for FreeBSD in the >> past (interrupt filters, for example), and the object oriented approach >> there is certainly interesting, but I don't see it as a cure all to >> stability or ease. > > > The IOKit isn't a cure-all, nor is an OO viewpoint always the best > approach. There isn't too much difference between inheriting the right > behavior and having stuff like this in every driver: > > static device_method_t mypci_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, mypci_probe), > DEVMETHOD(device_attach, mypci_attach), > DEVMETHOD(device_detach, mypci_detach), > DEVMETHOD(device_shutdown, mypci_shutdown), > DEVMETHOD(device_suspend, mypci_suspend), > DEVMETHOD(device_resume, mypci_resume), > { 0, 0 } > }; > > On the other hand, using inheritence for drivers seems to work pretty > well in practice, and the notion of encapsulation seems to help Darwin > avoid running into nearly as many lock-order reversals and layering > violations. > Again, IOKit doesn't cover pseudo drivers, and it papers over locking by providing high level serialization constructs. It would be interesting to write an IOKit driver two different ways, one that uses work loops and one that uses mutexes directly, as see if there is any performance difference on SMP. Until then, it's hard to say that work loops have a practical advantage in high performance environments. I'm starting to see evidence in FreeBSD that excessive serialization in device drivers is not good. Also, workloops aren't available outside of IOKit, and Darwin provides no good tools like WITNESS to detect and debugging locking problems, so it must be done through trial and error. That is really not fun. As interesting as Darwin is, I still prefer to work in FreeBSD. Scott From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:52:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0793816A41F for ; Thu, 10 Nov 2005 03:52:53 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE0543D48 for ; Thu, 10 Nov 2005 03:52:52 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id C34BD5F7C; Wed, 9 Nov 2005 22:52:51 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47190-01; Wed, 9 Nov 2005 22:52:50 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 214F55C67; Wed, 9 Nov 2005 22:52:50 -0500 (EST) Message-ID: <4372C410.5060707@mac.com> Date: Wed, 09 Nov 2005 22:52:48 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> <4372AED7.9000403@elischer.org> <4372B360.50203@samsco.org> In-Reply-To: <4372B360.50203@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: Poul-Henning Kamp , Julian Elischer , current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 03:52:53 -0000 Scott Long wrote: > Julian Elischer wrote: [ ... ] >> but if we could implement it we could run apple drivers.... >> (when they move to x86) > > No, we can't, unless we emulate the rest of the kernel API in OSX. > IOKit doesn't describe the entire kernel API. Think of it as 'newbus > done right' and nothing more. The rest of the kernel interfaces are > up for grabs. Some look and act like their BSD counterparts, some do > not. Scott's right that the IOKit is not a complete set of calls. The primary thing [1] that would be missing for Apple's drivers would be Mach messaging and Mach memory calls, which provide some of the underlying serialization capabilites of events, or clearly pertain to DMA (respectively). Apple has a portability layer written for Solaris, HP/UX, and even Windows which has a nmserver daemon which handles Mach messaging, and a shim for Mach memory calls using the SysV shared-memory interface. This has been included with PDO/EOF, WebObjects, and the FoundationKit packages with slight name variantions over time. The code is probably used by the ports of lookupd and netinfod...? -- -Chuck [1]: The complete KPI list for compliant drivers ought to be: com.apple.kernel.iokit, com.apple.kernel.libkern ...which would be enough for open source drivers, but a complete emulation layer would probably involve much of: com.apple.kernel, com.apple.kernel.mach, com.apple.kernel.bsd, com.apple.kernel.libkern, com.apple.kernel.iokit Fortunately, the upstream BSD layer is reasonably close to what FreeBSD has, except for Mach exception handling versus traditional BSD signals. MachO is not that different from ELF, and GCC already supports the BFD for it. There is some difference in dynamic linking semantics and namespaces, and someone would have to figure out the C++ name mangling, too. If this part was done, you might obtain reasonable compatibility with closed drivers available as binaries only, similar to what Project Evil/NDIS does now. From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 20:05:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B1E116A41F; Wed, 9 Nov 2005 20:05:00 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A7443D48; Wed, 9 Nov 2005 20:04:59 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id BB5D22F8D; Wed, 9 Nov 2005 14:04:58 -0600 (CST) Date: Wed, 9 Nov 2005 14:04:58 -0600 To: Robert Watson Message-ID: <20051109200458.GA26742@soaustin.net> References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109093920.GA45506@samodelkin.net> <20051109110903.583bb72d.lists@yazzy.org> <20051109121720.M39365@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051109121720.M39365@fledge.watson.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Thu, 10 Nov 2005 04:12:07 +0000 Cc: Marcin Jessa , current@freebsd.org, Max Khon Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Nov 2005 20:05:00 -0000 On Wed, Nov 09, 2005 at 12:20:14PM +0000, Robert Watson wrote: > My hope is that in the next year or so, things will settle down > significantly as we begin to flush the last of the non-MPSAFE drivers > from the system, and reach a point where all device drivers can use > consistent synchronization. If we are working towards that, I'd like to see someone contact the suppliers of the binary-only drivers and tell them that's where we're heading. IMHO we are starting to win back some 'mind-share' out there in the real world with 6.0 and we should build on that momentum. mcl From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 02:54:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3D7816A41F; Thu, 10 Nov 2005 02:54:00 +0000 (GMT) (envelope-from jr@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E7A43D48; Thu, 10 Nov 2005 02:53:59 +0000 (GMT) (envelope-from jr@opal.com) Received: from linwhf.opal.com (118.79.171.66.subscriber.vzavenue.net [66.171.79.118]) by smtp.vzavenue.net (MOS 3.7.1-GA) with ESMTP id DGW29571; Wed, 9 Nov 2005 21:49:42 -0500 (EST) Received: from ASSP-nospam (localhost [127.0.0.1]) by linwhf.opal.com (8.13.4/8.13.4) with ESMTP id jAA2nglW010371; Wed, 9 Nov 2005 21:49:42 -0500 (EST) (envelope-from jr@opal.com) Received: from 127.0.0.1 ([127.0.0.1] helo=linwhf.opal.com) by ASSP-nospam ; 10 Nov 05 02:49:42 -0000 Received: (from jr@localhost) by linwhf.opal.com (8.13.4/8.13.4/Submit) id jAA2nfSv010370; Wed, 9 Nov 2005 21:49:41 -0500 (EST) (envelope-from jr) Date: Wed, 9 Nov 2005 21:49:41 -0500 From: "J.R. Oldroyd" To: Sean McNeil Message-ID: <20051110024941.GA987@linwhf.opal.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131424479.1341.3.camel@server.mcneil.com> User-Agent: Mutt/1.4.2.1i X-Junkmail-Status: score=0/50, host=smtp.vzavenue.net X-Mailman-Approved-At: Thu, 10 Nov 2005 04:13:04 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 02:54:00 -0000 Experiencing the problem over here, too. # ifconfig gif0 gif0: flags=8051 mtu 1280 tunnel inet 66.171.79.118 --> 64.86.88.116 inet6 2001:5c0:8fff:fffe::553 --> 2001:5c0:8fff:fffe::552 prefixlen 128 inet6 fe80::20c:6eff:fe75:69aa%gif0 prefixlen 64 scopeid 0x5 # ping6 2001:5c0:8fff:fffe::553 PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::553 --> 2001:5c0:8fff:fffe::553 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=0 hlim=64 time=1.658 ms 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=1 hlim=64 time=0.720 ms 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=2 hlim=64 time=0.681 ms ^C Ping6 works fine: However TCP traffic is broke, for example, when I try to telnet to the POP3 server here, I observe that pf is blocking the server's response packets with this error: # telnet 2001:5c0:8fff:fffe::553 110 Trying 2001:5c0:8fff:fffe::553... ^C from pflog: 21:45:03.080452 rule 0/0(match): block in on gif0: 2001:5c0:8fff:fffe::553.110 > 2001:5c0:8fff:fffe::553.56716: tcp 36 [bad hdr length 8 - too short, < 20] This did not happen on earlier 6.0-current. -jr From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:02:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1901016A41F; Thu, 10 Nov 2005 03:02:28 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id B26F143D45; Thu, 10 Nov 2005 03:02:27 +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 6B169F24F0; Wed, 9 Nov 2005 19:02:27 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24115-01; Wed, 9 Nov 2005 19:02:27 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id EC147F2442; Wed, 9 Nov 2005 19:02:26 -0800 (PST) From: Sean McNeil To: "J.R. Oldroyd" In-Reply-To: <20051110024941.GA987@linwhf.opal.com> References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Wed, 09 Nov 2005 19:02:26 -0800 Message-Id: <1131591746.24065.3.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Thu, 10 Nov 2005 04:30:35 +0000 Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.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, 10 Nov 2005 03:02:28 -0000 On Wed, 2005-11-09 at 21:49 -0500, J.R. Oldroyd wrote: > Experiencing the problem over here, too. > > # ifconfig gif0 > gif0: flags=8051 mtu 1280 > tunnel inet 66.171.79.118 --> 64.86.88.116 > inet6 2001:5c0:8fff:fffe::553 --> 2001:5c0:8fff:fffe::552 prefixlen 128 > inet6 fe80::20c:6eff:fe75:69aa%gif0 prefixlen 64 scopeid 0x5 > > # ping6 2001:5c0:8fff:fffe::553 > PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::553 --> 2001:5c0:8fff:fffe::553 > 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=0 hlim=64 time=1.658 ms > 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=1 hlim=64 time=0.720 ms > 16 bytes from 2001:5c0:8fff:fffe::553, icmp_seq=2 hlim=64 time=0.681 ms > ^C > > Ping6 works fine: > > However TCP traffic is broke, for example, when I try to telnet to the POP3 > server here, I observe that pf is blocking the server's response packets with > this error: > > # telnet 2001:5c0:8fff:fffe::553 110 > Trying 2001:5c0:8fff:fffe::553... > ^C > > from pflog: > 21:45:03.080452 rule 0/0(match): block in on gif0: 2001:5c0:8fff:fffe::553.110 > 2001:5c0:8fff:fffe::553.56716: tcp 36 [bad hdr length 8 - too short, < 20] > > This did not happen on earlier 6.0-current. Oh Boy! This is very interesting. I took a look at my ipfw show during a ping6 and see the problem. The revpath is messed up. I took out my rule: add deny all from any to any not verrevpath in via dc0 and ping6 now works. Thanks for the clue! This should be fixed. I have no idea why the revpath is no longer valid. Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 03:13:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFC5716A41F; Thu, 10 Nov 2005 03:13:04 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ADA543D45; Thu, 10 Nov 2005 03:13: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 506E2F24F3; Wed, 9 Nov 2005 19:13:04 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24115-03; Wed, 9 Nov 2005 19:13:04 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DFB37F1A30; Wed, 9 Nov 2005 19:13:03 -0800 (PST) From: Sean McNeil To: SUZUKI Shinsuke In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> Content-Type: text/plain Organization: Sean McNeil Consulting, Inc Date: Wed, 09 Nov 2005 19:13:03 -0800 Message-Id: <1131592383.24386.2.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Thu, 10 Nov 2005 04:35:19 +0000 Cc: jr@opal.com, ume@freebsd.org, current@freebsd.org Subject: Re: TCPv6 unexpectedly dropped by PF / Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sean@mcneil.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, 10 Nov 2005 03:13:05 -0000 On Wed, 2005-11-09 at 18:59 -0800, SUZUKI Shinsuke wrote: > #I changed the ML title, since it's a different problem from Sean's > #one. > > >>>>> On Wed, 9 Nov 2005 21:49:41 -0500 > >>>>> jr@opal.com("J.R. Oldroyd") said: > > > However TCP traffic is broke, for example, when I try to telnet to the POP3 > > server here, I observe that pf is blocking the server's response packets with > > this error: > > > > # telnet 2001:5c0:8fff:fffe::553 110 > > Trying 2001:5c0:8fff:fffe::553... > > ^C > > > > from pflog: > > 21:45:03.080452 rule 0/0(match): block in on gif0: 2001:5c0:8fff:fffe::553.110 > 2001:5c0:8fff:fffe::553.56716: tcp 36 [bad hdr length 8 - too short, < 20] > > > > This did not happen on earlier 6.0-current. > > Could you please tell me the specific PF rule which caused the above match? My bet is on norevpath :) From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 04:37:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92BAA16A41F for ; Thu, 10 Nov 2005 04:37:22 +0000 (GMT) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A88543D45 for ; Thu, 10 Nov 2005 04:37:22 +0000 (GMT) (envelope-from kirk@strauser.com) Received: from localhost (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id 1E4A1222401 for ; Wed, 9 Nov 2005 22:37:21 -0600 (CST) Received: from kanga.honeypot.net ([127.0.0.1]) by localhost (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07076-12 for ; Wed, 9 Nov 2005 22:37:20 -0600 (CST) Received: from janus.daycos.com (janus.daycos.com [204.26.70.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTP id 754002204A6 for ; Wed, 9 Nov 2005 22:37:20 -0600 (CST) From: Kirk Strauser To: freebsd-current@freebsd.org Date: Wed, 9 Nov 2005 22:37:14 -0600 User-Agent: KMail/1.8.2 References: <20051108232855.2d1b7df5.lists@yazzy.org> <437246C5.2030607@elischer.org> <1A496451-166E-46F1-8363-19F117156FEE@mac.com> In-Reply-To: <1A496451-166E-46F1-8363-19F117156FEE@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1669947.6B3dHo9iMj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200511092237.19062.kirk@strauser.com> X-Virus-Scanned: amavisd-new at honeypot.net Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 04:37:22 -0000 --nextPart1669947.6B3dHo9iMj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 09 November 2005 15:23, Charles Swiger wrote: > Of course, it's easier to say such things then to write the code, but > Apple has achieved pretty good results from the IOKit.=20 I'm really out of my depth here, but the one thing Apple seems to have=20 accomplished with IOKit is abysmal performance. When it no longer takes me= =20 four times longer to backup an iMac than a much slower FreeBSD machine with= =20 an older drive, I'll be more impressed with their technology. =2D-=20 Kirk Strauser --nextPart1669947.6B3dHo9iMj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iD8DBQBDcs5/5sRg+Y0CpvERArz1AJwJixzT5zUzO0xQQKji3H/jujNvgwCePytX +NQzzLrjjx74kLSGeGMTjPI= =kjSM -----END PGP SIGNATURE----- --nextPart1669947.6B3dHo9iMj-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 06:08:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6584616A41F for ; Thu, 10 Nov 2005 06:08:50 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFDCE43D45 for ; Thu, 10 Nov 2005 06:08:49 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 366825F7C; Thu, 10 Nov 2005 01:08:49 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36831-04; Thu, 10 Nov 2005 01:08:47 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id BDD8A5D82; Thu, 10 Nov 2005 01:08:46 -0500 (EST) Message-ID: <4372E3ED.8070803@mac.com> Date: Thu, 10 Nov 2005 01:08:45 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <1566.1131574723@critter.freebsd.dk> <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> <43729ED9.9050204@samsco.org> <4372BB3E.5030304@mac.com> <4372C112.5000105@samsco.org> In-Reply-To: <4372C112.5000105@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 06:08:50 -0000 Scott Long wrote: > Chuck Swiger wrote: [ ...many lines deleted... ] >>> Remember that the target audience for much of the Apple documentation is >>> people who have never programmed in a Unix kernel before, be they coming >>> from Windows or coming from OS9. In fact, the Apple docs go out of >>> their way to discourage you from writing kernel modules entirely. >> >> Sure-- don't you agree that anything which can be done in userland, >> generally ought to be done there? Apple has to contend with >> developers who are looking to hook into the vertical blanking handler >> for screensavers and clock programs and who knows what else, just like >> they did in OS 9. Discouraging such things from going into the kernel >> is a good idea. Retained for context. >> Also remember that Mach is closer to being a microkernel than the >> other BSD kernels are, and the philosophy is showing in the design. >> That doesn't mean it's always the best approach, but Mach feels more >> consistent to me. > > The use of Mach in OSX in a whole lot more limited that you might think. You're talking about what someone else might think? Telepathy...? > The three uses are the BSD+IOkit kernel, the window server, and the > security server. The filesystems are still inside the BSD task, as are > most drivers. The exception here is certain kinds of USB peripheral > drivers. The USB hardware driver itself is still inside the kernel task. There are plenty of reasons why normal userland apps might use Mach messaging or VM calls directly, particularly things like databases which want to control their own paging behavior, or things which value both latency and bandwidth. It's also rather common for Apple's system daemons to use Mach messaging, a quick test suggests that 3 out of 4 do: [ ...pasted as quoted-text to avoid wrapping, I hope... ] > % uname -a > Darwin pan.codefab.com 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc > % ps auxw | grep root | sort -n +1 | head -20 > root 1 0.0 0.1 28356 516 ?? S root 23 0.0 0.1 27272 504 ?? Ss Fri03PM 0:00.01 /sbin/dynamic_pager -F /private/var/vm/swapfile > root 27 0.0 0.9 30648 4692 ?? Ss Fri03PM 0:05.85 kextd > root 54 0.0 0.7 29928 3920 ?? Ss Fri03PM 0:01.03 /usr/sbin/configd > root 55 0.0 1.0 29492 5056 ?? Ss Fri03PM 0:05.51 /usr/sbin/coreaudiod > root 56 0.0 0.6 27788 3128 ?? Ss Fri03PM 0:00.72 /usr/sbin/diskarbitrationd > root 57 0.0 0.3 28328 1644 ?? Ss Fri03PM 0:00.10 /usr/sbin/memberd -x > root 58 0.0 0.8 29232 4356 ?? Ss Fri03PM 0:08.49 /usr/sbin/securityd > root 60 0.0 0.2 27872 952 ?? Ss Fri03PM 0:02.66 /usr/sbin/notifyd > root 61 0.0 1.1 31088 5620 ?? Ss Fri03PM 0:05.16 /usr/sbin/DirectoryService > root 62 0.0 0.1 28252 744 ?? Ss Fri03PM 0:00.01 /usr/sbin/KernelEventAgent > root 63 0.0 0.5 28088 2792 ?? Ss Fri03PM 0:30.89 /usr/sbin/mDNSResponder -launchdaemon > root 64 0.1 0.2 27600 1168 ?? Ss Fri03PM 0:06.23 /usr/sbin/netinfod -s local > root 73 0.0 0.4 27680 2060 ?? Ss Fri03PM 0:00.36 /usr/sbin/distnoted > root 79 0.0 0.2 27256 836 ?? Ss Fri03PM 3:50.77 /usr/sbin/update > root 87 0.0 2.0 40148 10428 ?? Ss Fri03PM 0:02.09 /System/Library/CoreServices/coreservicesd > root 90 0.2 0.2 29332 1080 ?? Ss Fri03PM 0:19.00 /usr/sbin/lookupd > root 121 0.0 0.2 27516 848 ?? Ss Fri03PM 0:22.31 ntpd -f /var/run/ntp.drift -p /var/run/ntpd.pid > root 137 0.0 0.1 27260 672 ?? Ss Fri03PM 0:00.00 /usr/libexec/crashreporterd > root 157 0.0 0.1 29316 532 ?? Ss Fri03PM 0:00.00 nfsiod -n 4 [ ...minor pathname frobbing via awk deleted... ] > % grep -nl _mach_msg `cat /tmp/file_list` > /sbin/launchd > /sbin/dynamic_pager > /usr/libexec/kextd > /usr/sbin/configd > /usr/sbin/coreaudiod > /usr/sbin/diskarbitrationd > /usr/sbin/memberd > /usr/sbin/securityd > /usr/sbin/notifyd > /usr/sbin/DirectoryService > /usr/sbin/KernelEventAgent > /usr/sbin/mDNSResponder > /usr/sbin/lookupd > /usr/libexec/crashreporterd > % grep -nl _mach_msg `cat /tmp/file_list` | wc -l /usr/sbin > 14 As one might expect, portable BSD programs like ntpd and nfsiod do not use Mach messaging. Neither does update, the equivalent of [syncer], nor would /bin/sh, etc. >>> There is already a well established and stable API for doing DMA in >>> FreeBSD. Just about every driver in the kernel uses it. Why change? >> >> You mean isa_dmacascade(), isa_dma_acquire(), isa_dmainit() and >> bus_dma_*...? >> >> Eww. > > Uh, what? "Eww." as in "Yuck." :-) >> The forces of entropy are winning the fight to keep the ISA bus and >> DMA bounce buffers which must be less than 64K around forever, even on >> hardware which doesn't have such limitations. :-) > > Until the G5 was introduced, OSX never had to worry about making 32-bit > DMA work on >4GB memory configurations, and it certainly never worried > about ISA DMA. These are all still realities for i386 and amd64. There > are a lot of common I/O controllers out there, including traditional > ATA, that can't do 64-bit DMA and thus __require__ bounce buffers. There is nothing wrong with using bounce buffers when the situation requires it. The converse statement is also true: there *is* something wrong with using bounce buffers when it is not necessary. > Sparc64 requires that you program the IOMMU in order to do any DMA. > Busdma makes all of this transparent. And as for the G5, it does h0h0 > magic to make 32bit DMA work that is outside the scope of the IOMemory > classes. "h0h0 magic"...? :-) From what I can tell, both MacOS X and Solaris will happily use much of the first 4GB of physical RAM for DMA by wiring the pages down until the DMA transfer completes, and map those pages into either a 32-bit or 64-bit virtual address space, depending on what the process happens to be. > So, I'm sure what you have against the existing APIs, but they work well > for the FreeBSD environment. I prefer an event-driven work-loop API model rather than a continuation-based model, and I like Mach vm_objects a lot. There's an interesting discussion of the tradeoffs between Mach messaging versus BSD copyin and copyout here: http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/boundaries/chapter_14_section_3.html [ ... ] >> On the other hand, using inheritence for drivers seems to work pretty >> well in practice, and the notion of encapsulation seems to help Darwin >> avoid running into nearly as many lock-order reversals and layering >> violations. > > Again, IOKit doesn't cover pseudo drivers, and it papers over locking by > providing high level serialization constructs. If the system-provided API ensures correct serialization, that's better than getting serialization wrong, yes...? > It would be interesting to write an IOKit driver two different ways, one > that uses work loops and one that uses mutexes directly, as see if there is > any performance difference on SMP. Until then, it's hard to say that work > loops have a practical advantage in high performance environments. Indeed. Well, there appear to be a lot of dual-core machines coming down the road, so SMP is going to be a lot more common than it has been previously. I suspect that Solaris is going to do particularly well on quad-proc and higher boxes. > I'm starting to see evidence in FreeBSD that excessive serialization in > device drivers is not good. Also, workloops aren't available outside of > IOKit, and Darwin provides no good tools like WITNESS to detect and > debugging locking problems, so it must be done through trial and error. That > is really not fun. As interesting as Darwin is, I still prefer to work in > FreeBSD. Sure. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 06:27:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B32716A41F for ; Thu, 10 Nov 2005 06:27:59 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2861D43D46 for ; Thu, 10 Nov 2005 06:27:59 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 4C7B55F81; Thu, 10 Nov 2005 01:27:58 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36831-05; Thu, 10 Nov 2005 01:27:57 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 03E9E5F41; Thu, 10 Nov 2005 01:27:56 -0500 (EST) Message-ID: <4372E86B.5020301@mac.com> Date: Thu, 10 Nov 2005 01:27:55 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kirk Strauser References: <20051108232855.2d1b7df5.lists@yazzy.org> <437246C5.2030607@elischer.org> <1A496451-166E-46F1-8363-19F117156FEE@mac.com> <200511092237.19062.kirk@strauser.com> In-Reply-To: <200511092237.19062.kirk@strauser.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 06:27:59 -0000 Kirk Strauser wrote: > On Wednesday 09 November 2005 15:23, Charles Swiger wrote: >> Of course, it's easier to say such things then to write the code, but >> Apple has achieved pretty good results from the IOKit. > > I'm really out of my depth here, but the one thing Apple seems to have > accomplished with IOKit is abysmal performance. When it no longer takes me > four times longer to backup an iMac than a much slower FreeBSD machine with > an older drive, I'll be more impressed with their technology. Apple has shipped some really pokey 4200 RPM laptop-oriented drives with their lower-end systems. If that is the case, replacing the OEM drive with a 7200RPM one with 8MB cache would probably help out a lot, and only run about $75-100 depending on the size you want to get. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 10:54:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2CC516A41F; Thu, 10 Nov 2005 10:54:46 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFFB43D45; Thu, 10 Nov 2005 10:54:44 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029061.msg; Thu, 10 Nov 2005 16:54:35 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127012, updated: 9.11.2005] To: bug-followup@freebsd.org References: From: Victor Snezhko Date: Thu, 10 Nov 2005 16:54:34 +0600 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Processed: indor.net.tomline.ru, Thu, 10 Nov 2005 16:54:35 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: Max, freebsd-current@freebsd.org, Laier Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 10:54:47 -0000 --=-=-= Mark Tinguely has found the offending timer. The following patch fixes the problem for me: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=mld6.diff --- mld6.c Wed Nov 9 08:27:14 2005 *************** *** 640,645 **** --- 640,649 ---- mld6_stop_listening(in6m); ifma->ifma_protospec = NULL; LIST_REMOVE(in6m, in6m_entry); + if (in6m->in6m_timer != IN6M_TIMER_UNDEF) { + printf("in6_delmulti: timer 0x%p is still active\n", in6m->in6m_timer_ch); + mld_stoptimer(in6m); + } free(in6m->in6m_timer_ch, M_IP6MADDR); free(in6m, M_IP6MADDR); } --=-=-= Printf is fired with the patch applied, and panic doesn't occur. I have tested it on -current cvsupped with date=2005.10.21.16.25.00, and will test it on the fresh -current (in a day or two - I will need to recompile everything). The patch should work there although. According to the cvsweb, mld6.c didn't change. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 11:11:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63BAD16A41F for ; Thu, 10 Nov 2005 11:11:24 +0000 (GMT) (envelope-from mtrujillo@corp.vlex.com) Received: from mailroute4.intercomgi.net (mailroute4.intercomgi.net [213.171.234.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64FAF43D46 for ; Thu, 10 Nov 2005 11:11:20 +0000 (GMT) (envelope-from mtrujillo@corp.vlex.com) Received: from [192.168.10.177] (242.Red-217-126-10.staticIP.rima-tde.net [217.126.10.242]) (authenticated (0 bits)) by mailroute4.intercomgi.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id jAABNDaA027656 for ; Thu, 10 Nov 2005 12:23:13 +0100 Message-ID: <43732AC7.5050609@corp.vlex.com> Date: Thu, 10 Nov 2005 12:11:03 +0100 From: Manuel Trujillo Albarral User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------090404090208060305090905" Subject: Usb keyboard problems with a Dell Precision 380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 11:11:24 -0000 This is a multi-part message in MIME format. --------------090404090208060305090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. I have sent this e-mail to the hardware and usb lists without any result. Please, can you help me? First, i will apologize about my bad english... sorry... I'm trying to install FreeBSD 6.0-Release into a Dell Precision 380 workstation. The machine has an usb keyboard. I try with the "usb keyboard" from menu boot, also setting this "set hint.atkbd.0.flags="0x1"" from "options" in the menu boot option, or also with "set hint.acpi.0.disabled="1""... Is impossible to obtain keyboard when i arrive to sysinstall menu. Sometimes the machine hangup when arrive to "atkb" or keyboard section in the kernel load. Really, I can't understand what's happen... If a try with a FreeBSD 5.3 (Freesbie 1.1 livecd) all run ok. Here, attached to this mail, are two dmesg archives; one extracted from a knoppix 4.0 and another extrated from a Freesbie 1.1, and also two more archives from a lspci -vv from the knoppix 4.0, and the another from the Freesbie 1.1 livecd pciconf output. Anybody can help me, please? Thank you in advance. -- Manuel Trujillo Albarral Responsable de Sistemas VLEX NETWORKS S.L. http://www.vlex.com --------------090404090208060305090905 Content-Type: text/plain; name="dmesg_fbsd_5.3-rel.p2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_fbsd_5.3-rel.p2.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-RELEASE-p2 #5: Thu Dec 2 19:22:53 CET 2004 root@athlon.casadamico.net:/usr/obj/usr/src/sys/FREESBIE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1072209920 (1022 MB) avail memory = 1010360320 (963 MB) 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 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 11 at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 27.0 (no driver attached) pcib2: irq 11 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 11 at device 28.4 on pci0 pci3: on pcib3 pcib4: irq 10 at device 28.5 on pci0 pci4: on pcib4 bge0: mem 0xe7ef0000-0xe7efffff irq 10 at device 0.0 on pci4 miibus0: on bge0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:12:3f:76:2f:a7 uhci0: port 0xff80-0xff9f irq 9 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 0xff60-0xff7f irq 5 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 0xff40-0xff5f irq 3 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 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci3: port 0xff20-0xff3f irq 10 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) pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 5 at device 31.2 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) speaker0: port 0x61 on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xcf000-0xcffff,0xc0000-0xcefff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2992596570 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging unlimited md0: Preloaded image 31457280 bytes at 0xc098068a ad0: 238418MB [484406/16/63] at ata0-master UDMA33 acd0: DVDR at ata1-master UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [305170 x 2048 byte records] Mounting root from ufs:/dev/md0 md1.uzip: 12854 x 65536 blocks md2.uzip: 7798 x 65536 blocks md3.uzip: 277 x 65536 blocks md4.uzip: 2809 x 65536 blocks ext2fs: ad0s6: wrong magic number 0xffff (expected 0xef53) ext2fs: ad0s7: wrong magic number 0xffff (expected 0xef53) ext2fs: ad0s8: wrong magic number 0xffff (expected 0xef53) --------------090404090208060305090905 Content-Type: text/plain; name="dmesg_knoppix_4.0.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_knoppix_4.0.txt" Linux version 2.6.11 (root@Knoppix) (gcc-Version 3.3.5 (Debian 1:3.3.5-12)) #2 SMP Thu May 26 20:53:11 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fe8ac00 (usable) BIOS-e820: 000000003fe8ac00 - 000000003fe8cc00 (ACPI NVS) BIOS-e820: 000000003fe8cc00 - 000000003fe8ec00 (ACPI data) BIOS-e820: 000000003fe8ec00 - 0000000040000000 (reserved) BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved) BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved) BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) 126MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 On node 0 totalpages: 261770 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:16 HighMem zone: 32394 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP (v002 DELL ) @ 0x000feb00 ACPI: XSDT (v001 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd25f ACPI: FADT (v003 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd357 ACPI: SSDT (v001 DELL st_ex 0x00001000 INTL 0x20050211) @ 0xfffcef90 ACPI: MADT (v001 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd44b ACPI: BOOT (v001 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd4bd ACPI: ASF! (v016 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd4e5 ACPI: MCFG (v001 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd54c ACPI: HPET (v001 DELL WS 380 0x00000006 ASL 0x00000061) @ 0x000fd58a ACPI: DSDT (v001 DELL dt_ex 0x00001000 INTL 0x20050211) @ 0x00000000 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] disabled) ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 40000000:b0000000) Built 1 zonelists Kernel command line: ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=791 initrd=minirt.gz nomce quiet BOOT_IMAGE=knoppix BOOT_IMAGE=linux lang=es __iounmap: bad address c00fffd9 mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1032128k/1047080k available (1847k kernel code, 14320k reserved, 946k data, 292k init, 129576k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Using HPET for base-timer Using HPET for gettimeofday Detected 2993.058 MHz processor. Using hpet for high-res timesource Calibrating delay loop... 5931.00 BogoMIPS (lpj=2965504) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000641d 00000000 00000000 CPU: After vendor identify, caps: bfebfbff 20100000 00000000 00000000 0000641d 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 20100000 00000000 00000080 0000641d 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. Checking for popad bug... OK. CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 per-CPU timeslice cutoff: 2924.86 usecs. task migration cache decay timeout: 3 msecs. Booting processor 1/1 eip 3000 Initializing CPU#1 Calibrating delay loop... 5980.16 BogoMIPS (lpj=2990080) CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000641d 00000000 00000000 CPU: After vendor identify, caps: bfebfbff 20100000 00000000 00000000 0000641d 00000000 00000000 monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 20100000 00000000 00000080 0000641d 00000000 00000000 CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01 Total of 2 processors activated (11911.16 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 00000003 groups: 00000001 00000002 CPU1 attaching sched-domain: domain 0: span 00000003 groups: 00000002 00000001 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 878k freed NET: Registered protocol family 16 EISA bus registered PCI: PCI BIOS revision 2.10 entry at 0xfbc6f, last bus=5 PCI: Using MMCONFIG mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI5._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI6._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15) ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 10 devices PnPBIOS: Disabled by ACPI PNP SCSI subsystem initialized PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to bjorn.helgaas@hp.com ** so I can fix the driver. pnp: 00:00: ioport range 0x800-0x85f could not be reserved pnp: 00:00: ioport range 0xc00-0xc7f has been reserved pnp: 00:00: ioport range 0x860-0x8ff has been reserved Simple Boot Flag at 0x7a set to 0x1 audit: initializing netlink socket (disabled) audit(1131445645.867:0): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:01.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie03] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1c.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] Allocate Port Service[pcie03] ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1c.4 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] Allocate Port Service[pcie03] ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1c.5 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] Allocate Port Service[pcie03] vesafb: framebuffer at 0xd8000000, mapped to 0xf8880000, using 3072k, total 131072k vesafb: mode is 1024x768x16, linelength=2048, pages=1 vesafb: protected mode interface info at c000:d5d0 vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 100000K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe Probing IDE interface ide1... hdc: HL-DT-ST DVD+/-RW GWA4164B, ATAPI CD/DVD-ROM drive Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... ide1 at 0x170-0x177,0x376 on irq 15 hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache Uniform CD-ROM driver Revision: 3.20 libata version 1.10 loaded. ata_piix version 1.03 ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) -> IRQ 20 ata: 0x170 IDE port busy PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:207f ata1: dev 0 ATA, max UDMA/133, 488281250 sectors: lba48 ata1: dev 0 configured for UDMA/133 scsi0 : ata_piix Vendor: ATA Model: Maxtor 7L250S0 Rev: BANC Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 488281250 512-byte hdwr sectors (250000 MB) SCSI device sda: drive cache: write back SCSI device sda: 488281250 512-byte hdwr sectors (250000 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PS/2 Generic Mouse on isa0060/serio1 EISA: Probing bus 0 at eisa0 EISA: Detected 0 cards. NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 64Kbytes TCP established hash table entries: 131072 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 7, 786432 bytes) TCP: Hash tables configured (established 131072 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 15 Starting balanced_irq ACPI wakeup devices: VBTN PCI0 PCI4 PCI2 PCI3 PCI1 PCI5 PCI6 KBD USB0 USB1 USB2 USB3 ACPI: (supports S0 S1 S3 S4 S5) RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). seagate: ST0x/TMC-8xx not detected. Failed initialization of WD-7000 SCSI card! usbcore: registered new driver usbfs usbcore: registered new driver hub ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 21 (level, low) -> IRQ 21 ehci_hcd 0000:00:1d.7: PCI device 8086:27cc (Intel Corp.) PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: irq 21, pci mem 0xffa80800 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected USB Universal Host Controller Interface driver v2.2 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:1d.0: PCI device 8086:27c8 (Intel Corp.) PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: irq 21, io base 0xff80 uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 22 (level, low) -> IRQ 22 uhci_hcd 0000:00:1d.1: PCI device 8086:27c9 (Intel Corp.) PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: irq 22, io base 0xff60 uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18 uhci_hcd 0000:00:1d.2: PCI device 8086:27ca (Intel Corp.) PCI: Setting latency timer of device 0000:00:1d.2 to 64 uhci_hcd 0000:00:1d.2: irq 18, io base 0xff40 uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, low) -> IRQ 23 uhci_hcd 0000:00:1d.3: PCI device 8086:27cb (Intel Corp.) PCI: Setting latency timer of device 0000:00:1d.3 to 64 uhci_hcd 0000:00:1d.3: irq 23, io base 0xff20 uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5 hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ub: sizeof ub_scsi_cmd 64 ub_dev 2504 usb 4-2: new low speed USB device using uhci_hcd and address 2 usbcore: registered new driver ub Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. ieee1394: Initialized config rom entry `ip1394' sbp2: $Rev: 1219 $ Ben Collins ieee1394: sbp2: Driver forced to serialize I/O (serialize_io = 1) ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A cloop: Initializing cloop v2.02 cloop: loaded (max 8 devices) cloop: /cdrom/KNOPPIX/KNOPPIX: 82049 blocks, 65536 bytes/block, largest block is 65562 bytes. ISO 9660 Extensions: RRIP_1991A cloop: losetup_file: 65244 blocks, 65536 bytes/block, largest block is 65562 bytes. ISO 9660 Extensions: RRIP_1991A Registering unionfs version $Id: main.c,v 1.85 2005/03/14 22:19:49 dquigley Exp $ Freeing unused kernel memory: 292k freed Generic RTC Driver v1.07 ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [VBTN] Linux Kernel Card Services options: [pci] [cardbus] [pm] usbcore: registered new driver hiddev input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:1d.2-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver ts: Compaq touchscreen protocol output Serial: 8250/16550 driver $Revision: 1.90 $ 14 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A hw_random hardware driver 1.0.0 loaded tg3.c:v3.23 (February 15, 2005) ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:04:00.0 to 64 eth0: Tigon3 [partno(BCM5751PKFBG) rev 4001 PHY(5750)] (PCIX:100MHz:32-bit) 10/100/1000BaseT Ethernet 00:12:3f:76:2f:a7 eth0: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[1] TSOcap[1] EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem sda6 Ending clean XFS mount for filesystem: sda6 XFS mounting filesystem sda7 Ending clean XFS mount for filesystem: sda7 XFS mounting filesystem sda8 Ending clean XFS mount for filesystem: sda8 XFS mounting filesystem sda9 Ending clean XFS mount for filesystem: sda9 Adding 1116476k swap on /dev/sda10. Priority:-1 extents:1 NET: Registered protocol family 17 tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. Linux agpgart interface v0.100 (c) Dave Jones apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: disabled - APM is not SMP safe. --------------090404090208060305090905 Content-Type: text/plain; name="lspci_knoppix_4.0.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspci_knoppix_4.0.txt" 0000:00:00.0 Host bridge: Intel Corp.: Unknown device 2774 Subsystem: Dell: Unknown device 01a8 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [88] #0d [0000] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [a0] #10 [0141] 0000:00:1b.0 0403: Intel Corp.: Unknown device 27d8 (rev 01) Subsystem: Dell: Unknown device 01a8 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:1c.4 PCI bridge: Intel Corp.: Unknown device 27e0 (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:1c.5 PCI bridge: Intel Corp.: Unknown device 27e2 (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:1d.0 USB Controller: Intel Corp.: Unknown device 27c8 (rev 01) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 01a8 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [50] #0d [0000] 0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at ffa0 [size=16] Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:1f.3 SMBus: Intel Corp.: Unknown device 27da (rev 01) Subsystem: Dell: Unknown device 01a8 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E5E916A421; Thu, 10 Nov 2005 11:45:56 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF6E343D49; Thu, 10 Nov 2005 11:45:55 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id jAABjlt6022509; Thu, 10 Nov 2005 11:45:47 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.1/8.13.1) with ESMTP id jAABjlmS014044; Thu, 10 Nov 2005 11:45:47 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.1/8.13.1/Submit) with ESMTP id jAABjlVK014041; Thu, 10 Nov 2005 11:45:47 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Thu, 10 Nov 2005 11:45:47 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Robert Watson In-Reply-To: <20051102164157.A18382@fledge.watson.org> Message-ID: <20051104181424.R93043@ury.york.ac.uk> References: <1130943516.51544.34.camel@buffy.york.ac.uk> <20051102152322.GF93549@cicely12.cicely.de> <1130945849.51544.42.camel@buffy.york.ac.uk> <20051102164157.A18382@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: Poor NFS server performance in 6.0 with SMP and mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 11:45:56 -0000 On Wed, 2 Nov 2005, Robert Watson wrote: > On Wed, 2 Nov 2005, Gavin Atkinson wrote: >> On Wed, 2005-11-02 at 16:23 +0100, Bernd Walter wrote: >>> On Wed, Nov 02, 2005 at 02:58:36PM +0000, Gavin Atkinson wrote: >>>> I'm seeing incredibly poor performance when serving files from an SMP >>>> FreeBSD 6.0RC1 server to a Solaris 10 client. I've done some >>>> experimenting and have discovered that either removing SMP from the >>>> kernel, or setting debug.mpsafenet=0 in loader.conf massively improves >>>> the speed. Switching preemption off seems to also help. >>> Which scheduler? >> >> BSD. As I say, I'm running 6.0-RC1 with the standard GENERIC kernel, apart >> from the options I have listed as being changed above. Polling is >> therefore also not enabled. > > This does sound like a scheduling problem. I realize it's time-consuming, > but would it be possible to have you run each of the above test cases twice > more (or maybe even once) to confirm that in each case, the result is > reproduceable? I've recently been looking at a scheduling problem relating > to PREEMPTION and the netisr for loopback traffic, and is basically a result > of poorly timed context switching ending up being a worst cast scenario. I > suspect something similar is likely here. Have you tried varying the number > of nfsd worker threads on the server to see how that changes matters? No problem. Sorry it's taken so long to get back to you, it's been a hectic week :( Anyway, the trend is consistantly reproducable, although the results themselves can vary between runs in the SMP/mpsafenet cases by as much as 20%. Here are the averages of three reruns, which I've also done for ULE: 4BSD ULE No SMP, mpsafenet=1 78.7 62.7 No SMP, mpsafenet=0 71.1 76.0 No SMP, mpsafenet=1, no PREEMPTION 54.7 55.5 No SMP, mpsafenet=0, no PREEMPTION 73.6 77.6 SMP, mpsafenet=1 346.5 309.5 SMP, mpsafenet=0 56.9 88.4 SMP, mpsafenet=1, no PREEMPTION 320.2 136.6 SMP, mpsafenet=0, no PREEMPTION 57.0 77.9 The above are results for 4 nfsd servers (nfsd -n 4). It turns out that you were correct in thinking that the number of nfsd processes would make a difference, here are some timings for the GENERIC+SMP kernel (eg with PREEMPTION/4BSD, the slowest one above), with varying numbers of processes: 1 2 4 8 12 16 52.8 59.2 319.3 356.1 377.3 388.1 As before, all tests were done with freshly rebooted server and with a single "dry run" transfer to warm the vm cache up. The file transferred each time is 512meg worth of /dev/random output. I'm actually quite surprised about how much difference reducing the number of threads made. Does all of this information help track down the cause of the problem? I'm happy to time more transfers with different configs if you want to explore other avenues. Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 08:18:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90BFD16A41F for ; Thu, 10 Nov 2005 08:18:22 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D549A43D49 for ; Thu, 10 Nov 2005 08:18:21 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (adsl-66-124-231-46.dsl.snfc21.pacbell.net [66.124.231.46]) (authenticated bits=0) by igloo.linux.gr (8.13.4/8.13.4/Debian-3) with ESMTP id jAA8HmYb020452; Thu, 10 Nov 2005 10:17:56 +0200 Received: by flame.pc (Postfix, from userid 1001) id CA0AD1165C; Thu, 10 Nov 2005 00:17:36 -0800 (PST) Date: Thu, 10 Nov 2005 00:17:36 -0800 From: Giorgos Keramidas To: Eric Anderson Message-ID: <20051110081736.GA1855@flame.pc> References: <43724C11.5090201@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43724C11.5090201@centtech.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.436, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.96, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Mailman-Approved-At: Thu, 10 Nov 2005 12:12:17 +0000 Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 08:18:22 -0000 On 2005-11-09 13:20, Eric Anderson wrote: > I've been having issues lately when trying to bring up a new interface. > It's a hard problem to actually see, because it makes my machine > instantly reboot. > > Here's what I see: > Normally, I use ath0 for wireless, and occasionally I use em0. > Recently, when I was at a location with no wireless and no dhcp support, > I powered up my laptop, plugged in to em0, and did an ifconfig em0 xxx. > After a few seconds, the system spontaneously reboots. I figured > out that killing dhclient on that interface before attempting to > manually configure it helped. > > Now, I also tried to connect using ppp to a GPRS network (via bluetooth > through my cell phone). This used to work just fine, probably a few > months ago. This time, I killed all dhclients, connected the bluetooth > pieces, and then ran rfcomm_pppd, which creates a tun0 interface. When > the interface was created, and brought up without dhclient, everything > worked ok. When I accidentally left dhclient running, and tun0 was > created, when the device got it's IP address, machine rebooted. > > I have various machine logs/dmesg/etc here: > http://www.googlebit.com/freebsd/ > (labeled by date - look for the most current versions) > > I'm running 7.0-CURRENT as of a few days ago. How many days? You need at least a version that includes the following commit, otherwise you may have problems with ACPI or mbuf allocation: % glebius 2005-11-06 16:47:59 UTC % % FreeBSD src repository % % Modified files: % sys/kern kern_mbuf.c % Log: % Fix panic string in last revision. % % Revision Changes Path % 1.15 +1 -1 src/sys/kern/kern_mbuf.c From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 13:46:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E7E16A41F for ; Thu, 10 Nov 2005 13:46:27 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F13943D49 for ; Thu, 10 Nov 2005 13:46:26 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jAADkML6094003; Thu, 10 Nov 2005 07:46:22 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43734F29.7050101@centtech.com> Date: Thu, 10 Nov 2005 07:46:17 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Giorgos Keramidas References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> In-Reply-To: <20051110081736.GA1855@flame.pc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1167/Thu Nov 10 05:02:18 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 13:46:27 -0000 Giorgos Keramidas wrote: > On 2005-11-09 13:20, Eric Anderson wrote: > >>I've been having issues lately when trying to bring up a new interface. >> It's a hard problem to actually see, because it makes my machine >>instantly reboot. >> >>Here's what I see: >>Normally, I use ath0 for wireless, and occasionally I use em0. >>Recently, when I was at a location with no wireless and no dhcp support, >>I powered up my laptop, plugged in to em0, and did an ifconfig em0 xxx. >> After a few seconds, the system spontaneously reboots. I figured >>out that killing dhclient on that interface before attempting to >>manually configure it helped. >> >>Now, I also tried to connect using ppp to a GPRS network (via bluetooth >>through my cell phone). This used to work just fine, probably a few >>months ago. This time, I killed all dhclients, connected the bluetooth >>pieces, and then ran rfcomm_pppd, which creates a tun0 interface. When >>the interface was created, and brought up without dhclient, everything >>worked ok. When I accidentally left dhclient running, and tun0 was >>created, when the device got it's IP address, machine rebooted. >> >>I have various machine logs/dmesg/etc here: >>http://www.googlebit.com/freebsd/ >>(labeled by date - look for the most current versions) >> >>I'm running 7.0-CURRENT as of a few days ago. > > > How many days? You need at least a version that includes the following > commit, otherwise you may have problems with ACPI or mbuf allocation: > > % glebius 2005-11-06 16:47:59 UTC > % > % FreeBSD src repository > % > % Modified files: > % sys/kern kern_mbuf.c > % Log: > % Fix panic string in last revision. > % > % Revision Changes Path > % 1.15 +1 -1 src/sys/kern/kern_mbuf.c As of Monday, Nov 7th, and I've just checked, and I am indeed using this later version. It happened both before, and after this commit. It's pretty reproduceable, so I can do it anything, but fsck'ing my disks each time begins to get old :) If there's something I can do to help get some debugging, tell me. Since it's an insta-boot, I'm not sure how to catch that. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 14:24:25 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C9016A41F for ; Thu, 10 Nov 2005 14:24:25 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from maritaca.epm.br (disrouter.epm.br [200.17.25.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BDA543D45 for ; Thu, 10 Nov 2005 14:24:24 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from localhost (localhost.localdomain [127.0.0.1]) by maritaca.epm.br (Postfix) with ESMTP id 719053A8F for ; Thu, 10 Nov 2005 12:24:23 -0200 (BRDT) Received: from [172.22.1.166] (ricardo.epm.br [172.22.1.166]) by maritaca.epm.br (Postfix) with ESMTP id 1D9513A8D for ; Thu, 10 Nov 2005 12:24:18 -0200 (BRDT) Message-ID: <4373580B.3030407@yahoo.com.br> Date: Thu, 10 Nov 2005 12:24:11 -0200 From: "Ricardo A. Reis" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051024) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit UNIFESP-Virus-Scanned: by amavisd-new at dis.epm.br Cc: Subject: ahd0: Invalid Sequencer interrupt occurred. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 14:24:25 -0000 Hi all, The University where i work recent acquire a new server, i install FreeBSD 6.0 and update for STABLE yestarday, in dmesg i see this messages"" ahd0: Invalid Sequencer interrupt occurred. full-dmesg-output Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-STABLE #0: Wed Nov 9 01:03:14 UTC 2005 root@:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 Hyperthreading: 2 logical CPUs real memory = 1073152000 (1023 MB) avail memory = 1041080320 (992 MB) 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 ioapic2 irqs 48-71 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 5 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 10 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 ahd0: port 0x2400-0x24ff,0x2000-0x20ff mem 0xdd200000-0xdd201fff irq 32 at device 2.0 on pci3 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x2c00-0x2cff,0x2800-0x28ff mem 0xdd202000-0xdd203fff irq 33 at device 2.1 on pci3 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pci2: at device 0.1 (no driver attached) pcib4: at device 0.2 on pci2 pci4: on pcib4 em0: port 0x3000-0x303f mem 0xdd300000-0xdd31ffff irq 54 at device 2.0 on pci4 em0: Ethernet address: 00:30:48:2e:71:a4 em0: Speed:N/A Duplex:N/A em1: port 0x3040-0x307f mem 0xdd320000-0xdd33ffff irq 55 at device 2.1 on pci4 em1: Ethernet address: 00:30:48:2e:71:a5 em1: Speed:N/A Duplex:N/A pci2: at device 0.3 (no driver attached) pcib5: irq 16 at device 4.0 on pci0 pci5: on pcib5 pcib6: irq 16 at device 6.0 on pci0 pci6: on pcib6 pcib7: at device 30.0 on pci0 pci7: on pcib7 pci7: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1420-0x142f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 1 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff 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 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle acd0: CDRW at ata0-master UDMA33 ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x23b Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x1] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x3] KERNEL_QFREEZE_COUNT[0x3] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0x7 NEXTSCB 0xff00 qinstart = 38 qinfifonext = 39 QINFIFO: 0xb WAITING_TID_QUEUES: Pending list: 11 FIFO_USE[0x0] SCB_CONTROL[0x48]:(STATUS_RCVD|DISCENB) SCB_SCSIID[0x87] Total 1 Kernel Free SCB list: 7 15 1 2 3 4 5 6 8 9 10 12 13 14 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xf SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0xb SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xf 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x0] ahd0: REG0 == 0xd260, SINDEX = 0x10e, DINDEX = 0x104 ahd0: SCBPTR == 0xf, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x7 CDB 12 20 0 80 88 b6 STACK: 0x236 0x2 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> ses0 at ahd0 bus 0 target 8 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 SMP: AP CPU #1 Launched! da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) Trying to mount root from ufs:/dev/da0s1a Thanks for help, Ricardo A. Reis UNIFESP Unix and Network Admin From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 14:50:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A2F016A41F; Thu, 10 Nov 2005 14:50:43 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2572943D48; Thu, 10 Nov 2005 14:50:43 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jAAEobHs057634; Thu, 10 Nov 2005 08:50:37 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jAAEobjn057630; Thu, 10 Nov 2005 08:50:37 -0600 (CST) (envelope-from tinguely) Date: Thu, 10 Nov 2005 08:50:37 -0600 (CST) From: Mark Tinguely Message-Id: <200511101450.jAAEobjn057630@casselton.net> To: bug-followup@freebsd.org, snezhko@indorsoft.ru In-Reply-To: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net Cc: max@love2party.net, freebsd-current@freebsd.org, Max@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 14:50:43 -0000 As a postscript: The problem was a dynamic timer was freed without being stopped first. Obviously, the printf() should be removed from the final fix. After this discovery, I went through all of the callout_init() calls in the kernel and looked at those that may be freed before possibly being stopped. Beside the one in netinet6/mld6.c, I have 5 more that initially look like the memory for the callout struction could also be freed and still not have been stopped. These paths are problably not traveled much (detaches for less mainstream components), but stopping the callout is cheap and not at all risky. I will look at the 5 cases again and suggest all of these callout at risk be stopped under the same fix. --Mark Tinguely From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 15:36:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10F1B16A41F; Thu, 10 Nov 2005 15:36:19 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4402743D48; Thu, 10 Nov 2005 15:36:17 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id 102E3625C; Fri, 11 Nov 2005 00:37:38 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93227-07; Fri, 11 Nov 2005 00:37:29 +0900 (JST) Received: from flora220.uki-uki.net (unknown [209.52.153.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id CD5A661C6; Fri, 11 Nov 2005 00:37:26 +0900 (JST) Date: Thu, 10 Nov 2005 07:34:53 -0800 Message-ID: From: SUZUKI Shinsuke To: sean@mcneil.com,jr@opal.com X-cite: xcite 1.33 In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> <1131591746.24065.3.camel@triton.mcneil.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 15:36:19 -0000 Hi, >>>>> On Wed, 09 Nov 2005 19:12:58 -0800 >>>>> suz@freebsd.org(SUZUKI Shinsuke) said: > Oh Boy! This is very interesting. I took a look at my ipfw show during > a ping6 and see the problem. The revpath is messed up. I took out my > rule: > add deny all from any to any not verrevpath in via dc0 > and ping6 now works. suz> I'll check it from this point of view. I think I've found the problem. Could you please try the following patch? If it's okay, I'll commit and MFC it. Thanks, ---- SUZUKI, Shinsuke @ KAME Project ----- Index: ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.106.2.4 diff -u -r1.106.2.4 ip_fw2.c --- ip_fw2.c 4 Nov 2005 20:26:14 -0000 1.106.2.4 +++ ip_fw2.c 10 Nov 2005 14:44:06 -0000 @@ -639,8 +639,14 @@ if (ro.ro_rt == NULL) return 0; - /* if ifp is provided, check for equality with rtentry */ - if (ifp != NULL && ro.ro_rt->rt_ifp != ifp) { + /* + * if ifp is provided, check for equality with rtentry + * We should use rt->rt_ifa->ifa_ifp, instead of rt->rt_ifp, + * to support the case of sending packets to an address of our own. + * (where the former interface is the first argument of if_simloop() + * (=ifp), the latter is lo0) + */ + if (ifp != NULL && ro.ro_rt->rt_ifa->ifa_ifp != ifp) { RTFREE(ro.ro_rt); return 0; } From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 15:42:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D0116A41F; Thu, 10 Nov 2005 15:42:08 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.kame.net (kame219.kame.net [203.178.141.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBBA443D46; Thu, 10 Nov 2005 15:42:06 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.kame.net (Postfix) with ESMTP id 44FD962B2; Fri, 11 Nov 2005 00:43:27 +0900 (JST) Received: from pc1.alaxala.kame.net ([127.0.0.1]) by localhost (pc1.alaxala.kame.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93346-03; Fri, 11 Nov 2005 00:43:22 +0900 (JST) Received: from flora220.uki-uki.net (unknown [209.52.153.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.kame.net (Postfix) with ESMTP id 40678625C; Fri, 11 Nov 2005 00:43:19 +0900 (JST) Date: Thu, 10 Nov 2005 07:40:49 -0800 Message-ID: From: SUZUKI Shinsuke To: snezhko@indorsoft.ru X-cite: xcite 1.33 In-Reply-To: References: User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Technical Marketing Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at alaxala.kame.net Cc: max@love2party.net, freebsd-current@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 15:42:08 -0000 >>>>> On Thu, 10 Nov 2005 16:54:34 +0600 >>>>> snezhko@indorsoft.ru(Victor Snezhko) said: > Mark Tinguely has found the offending timer. > The following patch fixes the problem for me: Thanks. sounds right for me. So please commit it if when you've finished the test with fresh -current. From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 15:54:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6BF816A41F for ; Thu, 10 Nov 2005 15:54:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6741F43D48 for ; Thu, 10 Nov 2005 15:54:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1BE3746BB2; Thu, 10 Nov 2005 10:54:26 -0500 (EST) Date: Thu, 10 Nov 2005 15:54:26 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Philip Kizer In-Reply-To: <20051109184311.Y85371@fledge.watson.org> Message-ID: <20051110154950.Q68007@fledge.watson.org> References: <200510191623.j9JGNSfr007356@magus.nostrum.com> <20051019175020.S60849@fledge.watson.org> <20051025110453.L6720@fledge.watson.org> <2E18CEAE-2A72-4387-B92E-DAED7CC7FACD@nostrum.com> <33E53AA7-2A01-4BBE-9674-8F54E008D0A8@nostrum.com> <0906B09C-B5A2-402E-BF39-57EBB20B2D4F@nostrum.com> <425C901E-3315-41EC-B2D9-C372A2110FF0@nostrum.com> <20051109184311.Y85371@fledge.watson.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-5185577-1131638066=:68007" Cc: freebsd-current@freebsd.org Subject: Re: Problem remains with FreeBSD 6.0-RELEASE as seen in RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 15:54:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-5185577-1131638066=:68007 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 9 Nov 2005, Robert Watson wrote: >> I have now had another live-lock after upgrading: >> >> http://www.nostrum.com/hang/hang.RELENG_6-trace-2005-11-09-0.txt >> Any other suggestions or pointers on how to identify this livelock? > > This looks like much the same issue in the UNIX domain sockets. I have > been looking at executing unp_gc in a deferred context, and have an > initial patch which I need to test some before I send to you. > Hopefully it will be ready for you to try out in a day or two. Last night I successfully sent this patch to the wrong person, as I'm chasing a number of different bugs currently. While it won't help with his quota-related problems, using a combination of patches (attached) I'm now able to run a set of file descriptor passing edge case regression tests successfully. I've committed the regression test to src/tools/regression/sockets/unix_passfd. This test should only be run once the patches are applied, needless to say. If you could try out the patches and let me know if things improve, that would be great. Thanks, Robert N M Watson --0-5185577-1131638066=:68007 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=closef_threadnull.diff Content-Transfer-Encoding: BASE64 Content-ID: <20051110155425.L68007@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=closef_threadnull.diff SW5kZXg6IGtlcm5fZGVzY3JpcC5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4va2Vybl9kZXNj cmlwLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI4Mw0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjI4NA0KZGlmZiAtdSAtcjEuMjgzIC1yMS4yODQNCi0t LSBrZXJuX2Rlc2NyaXAuYwkxIE5vdiAyMDA1IDE3OjEzOjA1IC0wMDAwCTEu MjgzDQorKysga2Vybl9kZXNjcmlwLmMJOSBOb3YgMjAwNSAyMDo1NDoyNSAt MDAwMAkxLjI4NA0KQEAgLTE4ODAsOSArMTg4MCwxMyBAQA0KIAkgKiBhIGZs YWcgaW4gdGhlIHVubG9jayB0byBmcmVlIE9OTFkgbG9ja3Mgb2JleWluZyBQ T1NJWA0KIAkgKiBzZW1hbnRpY3MsIGFuZCBub3QgdG8gZnJlZSBCU0Qtc3R5 bGUgZmlsZSBsb2Nrcy4NCiAJICogSWYgdGhlIGRlc2NyaXB0b3Igd2FzIGlu IGEgbWVzc2FnZSwgUE9TSVgtc3R5bGUgbG9ja3MNCi0JICogYXJlbid0IHBh c3NlZCB3aXRoIHRoZSBkZXNjcmlwdG9yLg0KKwkgKiBhcmVuJ3QgcGFzc2Vk IHdpdGggdGhlIGRlc2NyaXB0bywgYW5kIHRoZSB0aHJlYWQgcG9pbnRlcg0K KwkgKiB3aWxsIGJlIE5VTEwuICBDYWxsZXJzIHNob3VsZCBiZSBjYXJlZnVs IG9ubHkgdG8gcGFzcyBhDQorCSAqIE5VTEwgdGhyZWFkIHBvaW50ZXIgd2hl biB0aGVyZSByZWFsbHkgaXMgbm8gb3duaW5nDQorCSAqIGNvbnRleHQgdGhh dCBtaWdodCBoYXZlIGxvY2tzLCBvciB0aGUgbG9ja3Mgd2lsbCBiZQ0KKwkg KiBsZWFrZWQuDQogCSAqLw0KLQlpZiAoZnAtPmZfdHlwZSA9PSBEVFlQRV9W Tk9ERSkgew0KKwlpZiAoZnAtPmZfdHlwZSA9PSBEVFlQRV9WTk9ERSAmJiB0 ZCAhPSBOVUxMKSB7DQogCQlpbnQgdmZzbG9ja2VkOw0KIA0KIAkJdnAgPSBm cC0+Zl92bm9kZTsNCg== --0-5185577-1131638066=:68007 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=20051110-unpgc_task.diff Content-Transfer-Encoding: BASE64 Content-ID: <20051110155426.A68007@fledge.watson.org> Content-Description: Content-Disposition: attachment; filename=20051110-unpgc_task.diff SW5kZXg6IHVpcGNfdXNycmVxLmMNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMva2Vybi91aXBjX3VzcnJl cS5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNTgNCmRpZmYgLXUgLXIx LjE1OCB1aXBjX3VzcnJlcS5jDQotLS0gdWlwY191c3JyZXEuYwkzMSBPY3Qg MjAwNSAxNTo0MToyNSAtMDAwMAkxLjE1OA0KKysrIHVpcGNfdXNycmVxLmMJ MTAgTm92IDIwMDUgMTU6NTM6MTEgLTAwMDANCkBAIC01OSw2ICs1OSw3IEBA DQogI2luY2x1ZGUgPHN5cy9zeC5oPg0KICNpbmNsdWRlIDxzeXMvc3lzY3Rs Lmg+DQogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPg0KKyNpbmNsdWRlIDxzeXMv dGFza3F1ZXVlLmg+DQogI2luY2x1ZGUgPHN5cy91bi5oPg0KICNpbmNsdWRl IDxzeXMvdW5wY2IuaD4NCiAjaW5jbHVkZSA8c3lzL3Zub2RlLmg+DQpAQCAt MTEyLDYgKzExMywxNCBAQA0KICNkZWZpbmUJVU5QX0xPQ0tfQVNTRVJUKCkJ bXR4X2Fzc2VydCgmdW5wX210eCwgTUFfT1dORUQpDQogI2RlZmluZQlVTlBf VU5MT0NLX0FTU0VSVCgpCW10eF9hc3NlcnQoJnVucF9tdHgsIE1BX05PVE9X TkVEKQ0KIA0KKy8qDQorICogR2FyYmFnZSBjb2xsZWN0aW9uIG9mIGN5Y2xp YyBmaWxlIGRlc2NyaXB0b3Ivc29ja2V0IHJlZmVyZW5jZXMgb2NjdXJzDQor ICogYXN5bmNocm9ub3VzbHkgaW4gYSB0YXNrcXVldWUgY29udGV4dCBpbiBv cmRlciB0byBhdm9pZCByZWN1cnNpb24gYW5kDQorICogcmVlbnRyYW5jZSBp biB0aGUgVU5JWCBkb21haW4gc29ja2V0LCBmaWxlIGRlc2NyaXB0b3IsIGFu ZCBzb2NrZXQgbGF5ZXINCisgKiBjb2RlLiAgU2VlIHVucF9nYygpIGZvciBh IGZ1bGwgZGVzY3JpcHRpb24uDQorICovDQorc3RhdGljIHN0cnVjdCB0YXNr CXVucF9nY190YXNrOw0KKw0KIHN0YXRpYyBpbnQgICAgIHVucF9hdHRhY2go c3RydWN0IHNvY2tldCAqKTsNCiBzdGF0aWMgdm9pZCAgICB1bnBfZGV0YWNo KHN0cnVjdCB1bnBjYiAqKTsNCiBzdGF0aWMgaW50ICAgICB1bnBfYmluZChz dHJ1Y3QgdW5wY2IgKixzdHJ1Y3Qgc29ja2FkZHIgKiwgc3RydWN0IHRocmVh ZCAqKTsNCkBAIC0xMjAsNyArMTI5LDcgQEANCiBzdGF0aWMgdm9pZCAgICB1 bnBfZGlzY29ubmVjdChzdHJ1Y3QgdW5wY2IgKik7DQogc3RhdGljIHZvaWQg ICAgdW5wX3NodXRkb3duKHN0cnVjdCB1bnBjYiAqKTsNCiBzdGF0aWMgdm9p ZCAgICB1bnBfZHJvcChzdHJ1Y3QgdW5wY2IgKiwgaW50KTsNCi1zdGF0aWMg dm9pZCAgICB1bnBfZ2Modm9pZCk7DQorc3RhdGljIHZvaWQgICAgdW5wX2dj KF9fdW51c2VkIHZvaWQgKiwgaW50KTsNCiBzdGF0aWMgdm9pZCAgICB1bnBf c2NhbihzdHJ1Y3QgbWJ1ZiAqLCB2b2lkICgqKShzdHJ1Y3QgZmlsZSAqKSk7 DQogc3RhdGljIHZvaWQgICAgdW5wX21hcmsoc3RydWN0IGZpbGUgKik7DQog c3RhdGljIHZvaWQgICAgdW5wX2Rpc2NhcmQoc3RydWN0IGZpbGUgKik7DQpA QCAtNzczLDYgKzc4Miw3IEBADQogdW5wX2RldGFjaChzdHJ1Y3QgdW5wY2Ig KnVucCkNCiB7DQogCXN0cnVjdCB2bm9kZSAqdnA7DQorCWludCBsb2NhbF91 bnBfcmlnaHRzOw0KIA0KIAlVTlBfTE9DS19BU1NFUlQoKTsNCiANCkBAIC03 OTUsMTkgKzgwNSw4IEBADQogCX0NCiAJc29pc2Rpc2Nvbm5lY3RlZCh1bnAt PnVucF9zb2NrZXQpOw0KIAl1bnAtPnVucF9zb2NrZXQtPnNvX3BjYiA9IE5V TEw7DQotCWlmICh1bnBfcmlnaHRzKSB7DQotCQkvKg0KLQkJICogTm9ybWFs bHkgdGhlIHJlY2VpdmUgYnVmZmVyIGlzIGZsdXNoZWQgbGF0ZXIsDQotCQkg KiBpbiBzb2ZyZWUsIGJ1dCBpZiBvdXIgcmVjZWl2ZSBidWZmZXIgaG9sZHMg cmVmZXJlbmNlcw0KLQkJICogdG8gZGVzY3JpcHRvcnMgdGhhdCBhcmUgbm93 IGdhcmJhZ2UsIHdlIHdpbGwgZGlzcG9zZQ0KLQkJICogb2YgdGhvc2UgZGVz Y3JpcHRvciByZWZlcmVuY2VzIGFmdGVyIHRoZSBnYXJiYWdlIGNvbGxlY3Rv cg0KLQkJICogZ2V0cyB0aGVtIChyZXN1bHRpbmcgaW4gYSAicGFuaWM6IGNs b3NlZjogY291bnQgPCAwIikuDQotCQkgKi8NCi0JCXNvcmZsdXNoKHVucC0+ dW5wX3NvY2tldCk7DQotCQl1bnBfZ2MoKTsJLyogV2lsbCB1bmxvY2sgVU5Q LiAqLw0KLQl9IGVsc2UNCi0JCVVOUF9VTkxPQ0soKTsNCi0JVU5QX1VOTE9D S19BU1NFUlQoKTsNCisJbG9jYWxfdW5wX3JpZ2h0cyA9IHVucF9yaWdodHM7 DQorCVVOUF9VTkxPQ0soKTsNCiAJaWYgKHVucC0+dW5wX2FkZHIgIT0gTlVM TCkNCiAJCUZSRUUodW5wLT51bnBfYWRkciwgTV9TT05BTUUpOw0KIAl1bWFf emZyZWUodW5wX3pvbmUsIHVucCk7DQpAQCAtODE2LDYgKzgxNSw4IEBADQog CQl2cmVsZSh2cCk7DQogCQltdHhfdW5sb2NrKCZHaWFudCk7DQogCX0NCisJ aWYgKGxvY2FsX3VucF9yaWdodHMpDQorCQl0YXNrcXVldWVfZW5xdWV1ZSh0 YXNrcXVldWVfdGhyZWFkLCAmdW5wX2djX3Rhc2spOw0KIH0NCiANCiBzdGF0 aWMgaW50DQpAQCAtMTM5NSw3ICsxMzk2LDcgQEANCiAJdW1hX3pvbmVfc2V0 X21heCh1bnBfem9uZSwgbm1iY2x1c3RlcnMpOw0KIAlMSVNUX0lOSVQoJnVu cF9kaGVhZCk7DQogCUxJU1RfSU5JVCgmdW5wX3NoZWFkKTsNCi0NCisJVEFT S19JTklUKCZ1bnBfZ2NfdGFzaywgMCwgdW5wX2djLCBOVUxMKTsNCiAJVU5Q X0xPQ0tfSU5JVCgpOw0KIH0NCiANCkBAIC0xNTgxLDE0ICsxNTgyLDIwIEBA DQogfQ0KIA0KIC8qDQotICogdW5wX2RlZmVyIGlzIHRocmVhZC1sb2NhbCBk dXJpbmcgZ2FyYmFnZSBjb2xsZWN0aW9uLCBhbmQgZG9lcyBub3QgcmVxdWly ZQ0KLSAqIGV4cGxpY2l0IHN5bmNocm9uaXphdGlvbi4gIHVucF9nY2luZyBw cmV2ZW50cyBvdGhlciB0aHJlYWRzIGZyb20gZW50ZXJpbmcNCi0gKiBnYXJi YWdlIGNvbGxlY3Rpb24sIGFuZCBwZXJoYXBzIHNob3VsZCBiZSBhbiBzeCBs b2NrIGluc3RlYWQuDQorICogdW5wX2RlZmVyIGluZGljYXRlcyB3aGV0aGVy IGFkZGl0aW9uYWwgd29yayBoYXMgYmVlbiBkZWZlcmVkIGZvciBhIGZ1dHVy ZQ0KKyAqIHBhc3MgdGhyb3VnaCB1bnBfZ2MoKS4gIEl0IGlzIHRocmVhZCBs b2NhbCBhbmQgZG9lcyBub3QgcmVxdWlyZSBleHBsaWNpdA0KKyAqIHN5bmNo cm9uaXphdGlvbi4NCiAgKi8NCi1zdGF0aWMgaW50CXVucF9kZWZlciwgdW5w X2djaW5nOw0KK3N0YXRpYyBpbnQJdW5wX2RlZmVyOw0KKw0KK3N0YXRpYyBp bnQgdW5wX3Rhc2tjb3VudDsNCitTWVNDVExfSU5UKF9uZXRfbG9jYWwsIE9J RF9BVVRPLCB0YXNrY291bnQsIENUTEZMQUdfUkQsICZ1bnBfdGFza2NvdW50 LCAwLCAiIik7DQorDQorc3RhdGljIGludCB1bnBfcmVjeWNsZWQ7DQorU1lT Q1RMX0lOVChfbmV0X2xvY2FsLCBPSURfQVVUTywgcmVjeWNsZWQsIENUTEZM QUdfUkQsICZ1bnBfcmVjeWNsZWQsIDAsICIiKTsNCiANCiBzdGF0aWMgdm9p ZA0KLXVucF9nYyh2b2lkKQ0KK3VucF9nYyhfX3VudXNlZCB2b2lkICphcmcs IGludCBwZW5kaW5nKQ0KIHsNCiAJc3RydWN0IGZpbGUgKmZwLCAqbmV4dGZw Ow0KIAlzdHJ1Y3Qgc29ja2V0ICpzbzsNCkBAIC0xNTk3LDE1ICsxNjA0LDgg QEANCiAJaW50IG5maWxlc19zbmFwOw0KIAlpbnQgbmZpbGVzX3NsYWNrID0g MjA7DQogDQotCVVOUF9MT0NLX0FTU0VSVCgpOw0KLQ0KLQlpZiAodW5wX2dj aW5nKSB7DQotCQlVTlBfVU5MT0NLKCk7DQotCQlyZXR1cm47DQotCX0NCi0J dW5wX2djaW5nID0gMTsNCisJdW5wX3Rhc2tjb3VudCsrOw0KIAl1bnBfZGVm ZXIgPSAwOw0KLQlVTlBfVU5MT0NLKCk7DQogCS8qDQogCSAqIGJlZm9yZSBn b2luZyB0aHJvdWdoIGFsbCB0aGlzLCBzZXQgYWxsIEZEcyB0bw0KIAkgKiBi ZSBOT1QgZGVmZXJlZCBhbmQgTk9UIGV4dGVybmFsbHkgYWNjZXNzaWJsZQ0K QEAgLTE2MTgsOSArMTYxOCwxNiBAQA0KIAkJTElTVF9GT1JFQUNIKGZwLCAm ZmlsZWhlYWQsIGZfbGlzdCkgew0KIAkJCUZJTEVfTE9DSyhmcCk7DQogCQkJ LyoNCi0JCQkgKiBJZiB0aGUgZmlsZSBpcyBub3Qgb3Blbiwgc2tpcCBpdA0K KwkJCSAqIElmIHRoZSBmaWxlIGlzIG5vdCBvcGVuLCBza2lwIGl0IC0tIGNv dWxkIGJlIGENCisJCQkgKiBmaWxlIGluIHRoZSBwcm9jZXNzIG9mIGJlaW5n IG9wZW5lZCwgb3IgaW4gdGhlDQorCQkJICogcHJvY2VzcyBvZiBiZWluZyBj bG9zZWQuICBJZiB0aGUgZmlsZSBpcw0KKwkJCSAqICJjbG9zaW5nIiwgaXQg bWF5IGhhdmUgYmVlbiBtYXJrZWQgZm9yIGRlZmVycmVkDQorCQkJICogY29u c2lkZXJhdGlvbi4gIENsZWFyIHRoZSBmbGFnIG5vdyBpZiBzby4NCiAJCQkg Ki8NCiAJCQlpZiAoZnAtPmZfY291bnQgPT0gMCkgew0KKwkJCQlpZiAoZnAt PmZfZ2NmbGFnICYgRkRFRkVSKQ0KKwkJCQkJdW5wX2RlZmVyLS07DQorCQkJ CWZwLT5mX2djZmxhZyAmPSB+KEZNQVJLfEZERUZFUik7DQogCQkJCUZJTEVf VU5MT0NLKGZwKTsNCiAJCQkJY29udGludWU7DQogCQkJfQ0KQEAgLTE2NzAs MjIgKzE2NzcsNiBAQA0KIAkJCWlmIChzby0+c29fcHJvdG8tPnByX2RvbWFp biAhPSAmbG9jYWxkb21haW4gfHwNCiAJCQkgICAgKHNvLT5zb19wcm90by0+ cHJfZmxhZ3MmUFJfUklHSFRTKSA9PSAwKQ0KIAkJCQljb250aW51ZTsNCi0j aWZkZWYgbm90ZGVmDQotCQkJaWYgKHNvLT5zb19yY3Yuc2JfZmxhZ3MgJiBT Ql9MT0NLKSB7DQotCQkJCS8qDQotCQkJCSAqIFRoaXMgaXMgcHJvYmxlbWF0 aWNhbDsgaXQncyBub3QgY2xlYXINCi0JCQkJICogd2UgbmVlZCB0byB3YWl0 IGZvciB0aGUgc29ja2J1ZiB0byBiZQ0KLQkJCQkgKiB1bmxvY2tlZCAob24g YSB1bmlwcm9jZXNzb3IsIGF0IGxlYXN0KSwNCi0JCQkJICogYW5kIGl0J3Mg YWxzbyBub3QgY2xlYXIgd2hhdCB0byBkbw0KLQkJCQkgKiBpZiBzYndhaXQg cmV0dXJucyBhbiBlcnJvciBkdWUgdG8gcmVjZWlwdA0KLQkJCQkgKiBvZiBh IHNpZ25hbC4gIElmIHNid2FpdCBkb2VzIHJldHVybg0KLQkJCQkgKiBhbiBl cnJvciwgd2UnbGwgZ28gaW50byBhbiBpbmZpbml0ZQ0KLQkJCQkgKiBsb29w LiAgRGVsZXRlIGFsbCBvZiB0aGlzIGZvciBub3cuDQotCQkJCSAqLw0KLQkJ CQkodm9pZCkgc2J3YWl0KCZzby0+c29fcmN2KTsNCi0JCQkJZ290byByZXN0 YXJ0Ow0KLQkJCX0NCi0jZW5kaWYNCiAJCQkvKg0KIAkJCSAqIFNvLCBPaywg aXQncyBvbmUgb2Ygb3VyIHNvY2tldHMgYW5kIGl0IElTIGV4dGVybmFsbHkN CiAJCQkgKiBhY2Nlc3NpYmxlIChvciB3YXMgZGVmZXJlZCkuIE5vdyB3ZSBs b29rDQpAQCAtMTcwMCw2ICsxNjkxLDkgQEANCiAJfSB3aGlsZSAodW5wX2Rl ZmVyKTsNCiAJc3hfc3VubG9jaygmZmlsZWxpc3RfbG9jayk7DQogCS8qDQor CSAqIFhYWFJXOiBUaGUgZm9sbG93aW5nIGNvbW1lbnRzIG5lZWQgdXBkYXRp bmcgZm9yIGEgcG9zdC1TTVBuZyBhbmQNCisJICogZGVmZXJyZWQgdW5wX2dj KCkgd29ybGQsIGJ1dCBhcmUgc3RpbGwgZ2VuZXJhbGx5IGFjY3VyYXRlLg0K KwkgKg0KIAkgKiBXZSBncmFiIGFuIGV4dHJhIHJlZmVyZW5jZSB0byBlYWNo IG9mIHRoZSBmaWxlIHRhYmxlIGVudHJpZXMNCiAJICogdGhhdCBhcmUgbm90 IG90aGVyd2lzZSBhY2Nlc3NpYmxlIGFuZCB0aGVuIGZyZWUgdGhlIHJpZ2h0 cw0KIAkgKiB0aGF0IGFyZSBzdG9yZWQgaW4gbWVzc2FnZXMgb24gdGhlbS4N CkBAIC0xNzExLDcgKzE3MDUsNyBAQA0KIAkgKiB0aW1lcyAtLSBjb25zaWRl ciB0aGUgY2FzZSBvZiBzb2NrZXRzIEEgYW5kIEIgdGhhdCBjb250YWluDQog CSAqIHJlZmVyZW5jZXMgdG8gZWFjaCBvdGhlci4gIE9uIGEgbGFzdCBjbG9z ZSBvZiBzb21lIG90aGVyIHNvY2tldCwNCiAJICogd2UgdHJpZ2dlciBhIGdj IHNpbmNlIHRoZSBudW1iZXIgb2Ygb3V0c3RhbmRpbmcgcmlnaHRzICh1bnBf cmlnaHRzKQ0KLQkgKiBpcyBub24temVyby4gIElmIGR1cmluZyB0aGUgc3dl ZXAgcGhhc2UgdGhlIGdjIGNvZGUgdW5fZGlzY2FyZHMsDQorCSAqIGlzIG5v bi16ZXJvLiAgSWYgZHVyaW5nIHRoZSBzd2VlcCBwaGFzZSB0aGUgZ2MgY29k ZSB1bnBfZGlzY2FyZHMsDQogCSAqIHdlIGVuZCB1cCBkb2luZyBhIChmdWxs KSBjbG9zZWYgb24gdGhlIGRlc2NyaXB0b3IuICBBIGNsb3NlZiBvbiBBDQog CSAqIHJlc3VsdHMgaW4gdGhlIGZvbGxvd2luZyBjaGFpbi4gIENsb3NlZiBj YWxscyBzb29fY2xvc2UsIHdoaWNoDQogCSAqIGNhbGxzIHNvY2xvc2UuICAg U29jbG9zZSBjYWxscyBmaXJzdCAodGhyb3VnaCB0aGUgc3dpdGNoDQpAQCAt MTc4OCwxMiArMTc4MiwxMSBAQA0KIAkJCUZJTEVfVU5MT0NLKHRmcCk7DQog CQl9DQogCX0NCi0JZm9yIChpID0gbnVucmVmLCBmcHAgPSBleHRyYV9yZWY7 IC0taSA+PSAwOyArK2ZwcCkNCisJZm9yIChpID0gbnVucmVmLCBmcHAgPSBl eHRyYV9yZWY7IC0taSA+PSAwOyArK2ZwcCkgew0KIAkJY2xvc2VmKCpmcHAs IChzdHJ1Y3QgdGhyZWFkICopIE5VTEwpOw0KKwkJdW5wX3JlY3ljbGVkKys7 DQorCX0NCiAJZnJlZShleHRyYV9yZWYsIE1fVEVNUCk7DQotCXVucF9nY2lu ZyA9IDA7DQotDQotCVVOUF9VTkxPQ0tfQVNTRVJUKCk7DQogfQ0KIA0KIHZv aWQNCkBAIC0xODg0LDkgKzE4NzcsMTEgQEANCiBzdGF0aWMgdm9pZA0KIHVu cF9kaXNjYXJkKHN0cnVjdCBmaWxlICpmcCkNCiB7DQorCVVOUF9MT0NLKCk7 DQogCUZJTEVfTE9DSyhmcCk7DQogCWZwLT5mX21zZ2NvdW50LS07DQogCXVu cF9yaWdodHMtLTsNCiAJRklMRV9VTkxPQ0soZnApOw0KKwlVTlBfVU5MT0NL KCk7DQogCSh2b2lkKSBjbG9zZWYoZnAsIChzdHJ1Y3QgdGhyZWFkICopTlVM TCk7DQogfQ0K --0-5185577-1131638066=:68007-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:41:07 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BDEE16A41F for ; Thu, 10 Nov 2005 16:41:07 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from portpc-design.spb.ru (portpc-design.spb.ru [81.176.64.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE3A843D48 for ; Thu, 10 Nov 2005 16:41:06 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [85.140.139.77] (ppp85-140-139-77.pppoe.mtu-net.ru [85.140.139.77]) (authenticated bits=0) by portpc-design.spb.ru (8.13.5/8.13.5) with ESMTP id jAAGf21H042322 for ; Thu, 10 Nov 2005 19:41:02 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <43737817.8030300@mcsi.pp.ru> Date: Thu, 10 Nov 2005 19:40:55 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051109 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-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on 81.176.64.226 X-Virus-Status: Clean Cc: Subject: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 16:41:07 -0000 Hi. 1 boot of 3 I got similar panics in softclock(). kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x218 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06aa6ae stack pointer = 0x28:0xd4710cac frame pointer = 0x28:0xd4710cd4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 13 (swi4: clock sio) The trace is: softclock(0) ... +0x86 ithread_execute_handlers ithread_loop fork_exit form_trampoline softclock+0x86 is here (marked with an arrow) /* * softticks may be modified by hard clock, so cache * it while we work on a given bucket. */ curticks = softticks; bucket = &callwheel[curticks & callwheelmask]; c = TAILQ_FIRST(bucket); while (c) { depth++; ---> if (c->c_time != curticks) { c = TAILQ_NEXT(c, c_links.tqe); ++steps; Debugging shows that 'c' has the value of 0x210. Which is incorrect for sure. 'c_time' has an offset of 0x8, giving us fault virtual address. I'm using NDIS. It seems, that panic happens on first packet NDIS tries to send. This is when 'ntpdate' is being run at boot stage. As I said, I can reproduce it by rebooting a few times. Can anyone give a clue where to look in DDB further to help to resolve this problem? -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:42:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE3D016A41F; Thu, 10 Nov 2005 16:42:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5150043D60; Thu, 10 Nov 2005 16:42:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1709437 for multiple; Thu, 10 Nov 2005 11:44:21 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAAGg7p1066514; Thu, 10 Nov 2005 11:42:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 10 Nov 2005 11:40:13 -0500 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101140.15374.jhb@freebsd.org> X-Spam-Status: No, score=-2.2 required=4.2 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: max@love2party.net, snezhko@indorsoft.ru, bug-followup@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 16:42:18 -0000 On Thursday 10 November 2005 10:40 am, SUZUKI Shinsuke wrote: > >>>>> On Thu, 10 Nov 2005 16:54:34 +0600 > >>>>> snezhko@indorsoft.ru(Victor Snezhko) said: > > > > Mark Tinguely has found the offending timer. > > The following patch fixes the problem for me: > > Thanks. sounds right for me. > So please commit it if when you've finished the test with fresh -current. As a general rule you should be using callout_drain() before freeing a callout to handle the race condition where the callout is running on another CPU (so callout_stop can't stop it) while you are freeing it. Note that you can not use callout_drain() if you are holding any locks, though. In those cases you will need to defer the callout_drain() and free() until you have dropped the locks. Here's one example fix: Index: nd6.c =================================================================== RCS file: /usr/cvs/src/sys/netinet6/nd6.c,v retrieving revision 1.62 diff -u -r1.62 nd6.c --- nd6.c 22 Oct 2005 05:07:16 -0000 1.62 +++ nd6.c 3 Nov 2005 19:56:42 -0000 @@ -398,7 +398,7 @@ if (tick < 0) { ln->ln_expire = 0; ln->ln_ntick = 0; - callout_stop(&ln->ln_timer_ch); + callout_drain(&ln->ln_timer_ch); } else { ln->ln_expire = time_second + tick / hz; if (tick > INT_MAX) { -- 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 Nov 10 16:50:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 888B116A41F; Thu, 10 Nov 2005 16:50:53 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D5E743D46; Thu, 10 Nov 2005 16:50:51 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029127.msg; Thu, 10 Nov 2005 22:50:46 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127012, updated: 9.11.2005] To: SUZUKI Shinsuke References: From: Victor Snezhko Date: Thu, 10 Nov 2005 22:50:42 +0600 In-Reply-To: (SUZUKI Shinsuke's message of "Thu, 10 Nov 2005 07:40:49 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Thu, 10 Nov 2005 22:50:46 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: freebsd-current@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 16:50:53 -0000 SUZUKI Shinsuke writes: >> Mark Tinguely has found the offending timer. >> The following patch fixes the problem for me: > > Thanks. sounds right for me. > So please commit it if when you've finished the test with fresh -current. I'm not a committer :) In fact, I'm a novice in freebsd and just beginning to experiment with -current. I'll notify everybody when I finish testing this. Besides, after committing and closing the PR, we should wait for Mark's results about more rare cases. And fix them too. (I have removed bug-followup@ from the Cc in order not to fill PR's Audit-Trail section with this blablabla's) -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 17:03:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FAF316A429; Thu, 10 Nov 2005 17:03:01 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028F743D45; Thu, 10 Nov 2005 17:02:59 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029142.msg; Thu, 10 Nov 2005 23:02:52 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127012, updated: 9.11.2005] To: Mark Tinguely References: <200511101450.jAAEobjn057630@casselton.net> From: Victor Snezhko Date: Thu, 10 Nov 2005 23:02:47 +0600 In-Reply-To: <200511101450.jAAEobjn057630@casselton.net> (Mark Tinguely's message of "Thu, 10 Nov 2005 08:50:37 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Thu, 10 Nov 2005 23:02:52 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: max@love2party.net, freebsd-current@freebsd.org, Max@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 17:03:01 -0000 Mark Tinguely writes: > As a postscript: > > The problem was a dynamic timer was freed without being stopped first. > Obviously, the printf() should be removed from the final fix. > > After this discovery, I went through all of the callout_init() calls > in the kernel and looked at those that may be freed before possibly > being stopped. Beside the one in netinet6/mld6.c, I have 5 more > that initially look like the memory for the callout struction could > also be freed and still not have been stopped. These paths are problably > not traveled much (detaches for less mainstream components), but stopping > the callout is cheap and not at all risky. Not risky? I'm not an expert, but I think there might be issues when callout is stopped at the moment when on-timer function is executed (I see the following bad scenario: timer function begins to execute, then we call callout_stop(), then free all the necessary data structures and then control returns to the timer proc which could depend on the structures that are already freed) I.e. in each case we should check if callout_stop don't harm. On the other hand, callout_drain could introduce lock order issues (as John Baldwin pointed). > I will look at the 5 cases again and suggest all of these callout at > risk be stopped under the same fix. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:01:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 955EA16A420; Thu, 10 Nov 2005 18:01:54 +0000 (GMT) In-Reply-To: <43732AC7.5050609@corp.vlex.com> from Manuel Trujillo Albarral at "Nov 10, 2005 12:11:03 pm" To: mtrujillo@corp.vlex.com (Manuel Trujillo Albarral) Date: Thu, 10 Nov 2005 18:01:54 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110180154.955EA16A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: Usb keyboard problems with a Dell Precision 380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 18:01:54 -0000 [Charset ISO-8859-1 unsupported, filtering to ASCII...] > Hi. > > I have sent this e-mail to the hardware and usb lists without any > result. Please, can you help me? > > First, i will apologize about my bad english... sorry... > > I'm trying to install FreeBSD 6.0-Release into a Dell Precision 380 > workstation. The machine has an usb keyboard. > I try with the "usb keyboard" from menu boot, also setting this "set > hint.atkbd.0.flags="0x1"" from "options" in the menu boot option, or > also with "set hint.acpi.0.disabled="1""... Is impossible to obtain > keyboard when i arrive to sysinstall menu. Sometimes the machine hangup > when arrive to "atkb" or keyboard section in the kernel load. > Really, I can't understand what's happen... > If a try with a FreeBSD 5.3 (Freesbie 1.1 livecd) all run ok. What I think you really want to try is: set hint.atkbd.0.disabled="1" (You said "set hint.acpi.0.disable="1"" but that's not the same thing. You do _not_ want to disable ACPI. You _do_ want to disable the atkbd device.) It happens I just did an install on the machine in my office, and even if I select the "boot with USB keyboard" option from the boot menu, sysinstall _still_ uses the PS/2 keyboard. (Luckily, in my case, I have both the USB and PS/2 keyboard: the system is designed to use the PS/2 keyboard by default, and I added a USB keyboard and mouse later.) I think the problem is that as long as atkbd0 is detected (and FreeBSD/i386 steadfastly insists on detecting it even on some systems where there really isn't a PS/2 keyboard), it will default to using kdb0 attached to atkbd0, and the only way to change it is to run kbdcontrol later. But sysinstall does not run kbdcontrol. Disabling atkbd0 forces the USB keyboard to become kbd0. Then it works. In my case, hint.atkbd.0.disable="1" did the trick. I hope it works for you. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:22:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79B8E16A421 for ; Thu, 10 Nov 2005 18:22:58 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C5B43D48 for ; Thu, 10 Nov 2005 18:22:57 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so580913wxc for ; Thu, 10 Nov 2005 10:22:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C+wU9XcI8pIkg95rak9flEZNyJg1LVQp+v3rX5E5YmhtW7lm431mxHnU1zjWacxgsSZBntjbXkyn/MOWiOInogSwXdOBx0+1q+mDCimBju6mGH7wiD+OZXTc1zpwmp8M85G+1EAIMPMviAOT0Ofazn91ZcnLqqS5tZq0zt1uK3A= Received: by 10.70.69.7 with SMTP id r7mr1106806wxa; Thu, 10 Nov 2005 10:22:57 -0800 (PST) Received: by 10.70.54.18 with HTTP; Thu, 10 Nov 2005 10:22:57 -0800 (PST) Message-ID: <790a9fff0511101022i1dc9b00am5575162e7c140da7@mail.gmail.com> Date: Thu, 10 Nov 2005 12:22:57 -0600 From: Scot Hetzel To: Eric Anderson In-Reply-To: <43734F29.7050101@centtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> <43734F29.7050101@centtech.com> Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 18:22:58 -0000 > If there's something I can do to help get some debugging, tell me. > Since it's an insta-boot, I'm not sure how to catch that. > You need to enable the debugging options in your kernel, so that it breaks to the debugger instead of rebooting your system. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:46:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 691E616A420; Thu, 10 Nov 2005 18:46:35 +0000 (GMT) In-Reply-To: <43737817.8030300@mcsi.pp.ru> from Maxim Maximov at "Nov 10, 2005 07:40:55 pm" To: mcsi@mcsi.pp.ru (Maxim Maximov) Date: Thu, 10 Nov 2005 18:46:35 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110184635.691E616A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 18:46:35 -0000 > Hi. > > 1 boot of 3 I got similar panics in softclock(). > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x218 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06aa6ae > stack pointer = 0x28:0xd4710cac > frame pointer = 0x28:0xd4710cd4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 13 (swi4: clock sio) > > The trace is: > > softclock(0) ... +0x86 > ithread_execute_handlers > ithread_loop > fork_exit > form_trampoline > > softclock+0x86 is here (marked with an arrow) > > /* > * softticks may be modified by hard clock, so cache > * it while we work on a given bucket. > */ > curticks = softticks; > bucket = &callwheel[curticks & callwheelmask]; > c = TAILQ_FIRST(bucket); > while (c) { > depth++; > ---> if (c->c_time != curticks) { > c = TAILQ_NEXT(c, c_links.tqe); > ++steps; > > Debugging shows that 'c' has the value of 0x210. Which is incorrect for > sure. 'c_time' has an offset of 0x8, giving us fault virtual address. > I'm using NDIS. It seems, that panic happens on first packet NDIS tries > to send. This is when 'ntpdate' is being run at boot stage. > As I said, I can reproduce it by rebooting a few times. Can anyone give > a clue where to look in DDB further to help to resolve this problem? If you want us to give you clues, you have to give _US_ clues. For example, here are some of the things you didn't bother to say: - _WHICH_ windows driver are you using with NDIS? - _WHAT_ wireless card do you have? - Complete dmesg output from your system (note: verbose boot is not necessary, but _full_ output is necessary, i.e. don't remove things you think are unimportant) - Did you add your NDIS driver to /boot/loader.conf, or are you loading the driver after the system is running multiuser? - If you are loading the driver via /boot/loader.conf, did you try _not_ doing that, and loading it afterwards? - What kind of system is this? Laptop? Desktop? Stone knives and bearskins? - Is it SMP or UP? When you provide this information, maybe you will get help. NOTE: Windows NDIS drivers assume that by the time you intialize them, the entire OS is up and running, including scheduling and, if present, multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' state when it probes/attaches devices, and not all of the scheduling mechanisms are available yet (for example, you can not msleep() while cold == 1). This means loading your driver via /boot/loader.conf is something of a hit-or-miss proposition: sometimes they don't work right, sometimes they do. To be really safe, you should load them _after_ the system has come up all the way. Unfortunately, it's necessary to initialize the driver briefly in ndis_attach() in order to find out the device's station address. (You can only do it via MiniportQueryInformation(), and that only works after MiniportInitialize() has been called.) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:48:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AB5D16A41F for ; Thu, 10 Nov 2005 18:48:57 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC5E43D49 for ; Thu, 10 Nov 2005 18:48:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from webmail.centtech.com (mailbox.centtech.com [10.20.0.15]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jAAImtcZ098569; Thu, 10 Nov 2005 12:48:55 -0600 (CST) (envelope-from anderson@centtech.com) Received: from 10.20.200.100 (SquirrelMail authenticated user anderson); by otter.centtech.com with HTTP; Thu, 10 Nov 2005 12:48:55 -0600 (CST) Message-ID: <59876.10.20.200.100.1131648535.squirrel@10.20.200.100> In-Reply-To: <790a9fff0511101022i1dc9b00am5575162e7c140da7@mail.gmail.com> References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> <43734F29.7050101@centtech.com> <790a9fff0511101022i1dc9b00am5575162e7c140da7@mail.gmail.com> Date: Thu, 10 Nov 2005 12:48:55 -0600 (CST) From: "Eric Anderson" To: "Scot Hetzel" User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: ClamAV 0.82/1167/Thu Nov 10 05:02:18 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 18:48:57 -0000 Scot Hetzel said: >> If there's something I can do to help get some debugging, tell me. >> Since it's an insta-boot, I'm not sure how to catch that. >> > You need to enable the debugging options in your kernel, so that it > breaks to the debugger instead of rebooting your system. Which ones am I missing: http://www.googlebit.com/freebsd/kernelconfig.200511100648 Thanks! Eric -- ------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology You have my continuous partial attention ------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 18:57:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51C5816A41F for ; Thu, 10 Nov 2005 18:57:44 +0000 (GMT) (envelope-from tom@motd.dk) Received: from bart.motd.dk (port95.ds1-ro.adsl.cybercity.dk [212.242.60.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42F2E43D49 for ; Thu, 10 Nov 2005 18:57:42 +0000 (GMT) (envelope-from tom@motd.dk) Received: from localhost (localhost.motd.dk [127.0.0.1]) by bart.motd.dk (Postfix) with ESMTP id 68EDE60FC; Thu, 10 Nov 2005 20:01:43 +0100 (CET) Received: from bart.motd.dk ([127.0.0.1]) by localhost (bart.motd.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47777-05; Thu, 10 Nov 2005 20:01:38 +0100 (CET) Received: from homer (homer.motd.dk [192.168.10.3]) by bart.motd.dk (Postfix) with ESMTP id 4320360D2; Thu, 10 Nov 2005 20:01:38 +0100 (CET) From: "Tom Jensen" To: Date: Thu, 10 Nov 2005 19:57:32 +0100 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: <59876.10.20.200.100.1131648535.squirrel@10.20.200.100> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXmKCEz2W4b3h9tS2ymYg00xduabgAACTGQ Message-Id: <20051110190138.4320360D2@bart.motd.dk> X-Virus-Scanned: by amavisd-new at motd.dk Cc: 'Eric Anderson' Subject: RE: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 18:57:44 -0000 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Eric Anderson Sent: 10. november 2005 19:49 To: Scot Hetzel Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up Scot Hetzel said: >> If there's something I can do to help get some debugging, tell me. >> Since it's an insta-boot, I'm not sure how to catch that. >> > You need to enable the debugging options in your kernel, so that it > breaks to the debugger instead of rebooting your system. :Which ones am I missing: :http://www.googlebit.com/freebsd/kernelconfig.200511100648 :Thanks! :Eric :-- :------------------------------------------------------------- :Eric Anderson anderson@centtech.com Centaur Technology :You have my continuous partial attention :------------------------------------------------------------- :_______________________________________________ :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" Im also having this in my kernel options BREAK_TO_DEBUGGER options DEBUG_LOCKS - T From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:02:38 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4A7016A420; Thu, 10 Nov 2005 19:02:38 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from portpc-design.spb.ru (portpc-design.spb.ru [81.176.64.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F8E43D6D; Thu, 10 Nov 2005 19:02:25 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [85.140.139.77] (ppp85-140-139-77.pppoe.mtu-net.ru [85.140.139.77]) (authenticated bits=0) by portpc-design.spb.ru (8.13.5/8.13.5) with ESMTP id jAAJ2HJK074915; Thu, 10 Nov 2005 22:02:17 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <43739932.6060707@mcsi.pp.ru> Date: Thu, 10 Nov 2005 22:02:10 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051109 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Bill Paul References: <20051110184635.691E616A420@hub.freebsd.org> In-Reply-To: <20051110184635.691E616A420@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on 81.176.64.226 X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.ORG Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:02:39 -0000 Bill Paul wrote: >>Hi. >> >> 1 boot of 3 I got similar panics in softclock(). >> >>kernel trap 12 with interrupts disabled >> >> >>Fatal trap 12: page fault while in kernel mode >>cpuid = 0; apic id = 00 >>fault virtual address = 0x218 >>fault code = supervisor read, page not present >>instruction pointer = 0x20:0xc06aa6ae >>stack pointer = 0x28:0xd4710cac >>frame pointer = 0x28:0xd4710cd4 >>code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >>processor eflags = resume, IOPL = 0 >>current process = 13 (swi4: clock sio) >> >> The trace is: >> >>softclock(0) ... +0x86 >>ithread_execute_handlers >>ithread_loop >>fork_exit >>form_trampoline >> >> softclock+0x86 is here (marked with an arrow) >> >> /* >> * softticks may be modified by hard clock, so cache >> * it while we work on a given bucket. >> */ >> curticks = softticks; >> bucket = &callwheel[curticks & callwheelmask]; >> c = TAILQ_FIRST(bucket); >> while (c) { >> depth++; >>---> if (c->c_time != curticks) { >> c = TAILQ_NEXT(c, c_links.tqe); >> ++steps; >> >> Debugging shows that 'c' has the value of 0x210. Which is incorrect for >>sure. 'c_time' has an offset of 0x8, giving us fault virtual address. >> I'm using NDIS. It seems, that panic happens on first packet NDIS tries >>to send. This is when 'ntpdate' is being run at boot stage. >> As I said, I can reproduce it by rebooting a few times. Can anyone give >>a clue where to look in DDB further to help to resolve this problem? > > > If you want us to give you clues, you have to give _US_ clues. > > For example, here are some of the things you didn't bother to say: > > - _WHICH_ windows driver are you using with NDIS? bcmwl5.sys > - _WHAT_ wireless card do you have? It presents itself as ASUS 802.11g Network Adapter. Based on Broadcom chip. > - Complete dmesg output from your system (note: verbose boot is not > necessary, but _full_ output is necessary, i.e. don't remove things > you think are unimportant) Here it is. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #0: Tue Nov 8 20:52:36 MSK 2005 mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400> Logical CPUs per core: 2 real memory = 536674304 (511 MB) avail memory = 510435328 (486 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 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: irq 9 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 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 drm0: port 0x9800-0x98ff mem 0xe8000000-0xefffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized radeon 1.16.0 20050311 on minor 0 uhci0: port 0xe000-0xe01f 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 0xe400-0xe41f 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 0xe800-0xe81f 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 0xec00-0xec1f 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 ehci0: mem 0xfebffc00-0xfebfffff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to give up control usb4: timed out waiting for BIOS usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xa800-0xa8ff mem 0xfeafc000-0xfeafffff irq 18 at device 0.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:b9:f9:f8 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto cbb0: irq 16 at device 1.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 17 at device 1.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xfeafb000-0xfeafb7ff irq 18 at device 1.2 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:03:18:f3:bc fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:18:f3:bc fwe0: Ethernet address: 02:e0:18:18:f3:bc fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 1.3 (no driver attached) pci2: at device 1.4 (no driver attached) ndis0: mem 0xfeaf8000-0xfeaf9fff irq 17 at device 2.0 on pci2 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 00:0e:a6:c2:00:e4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xd400-0xd4ff,0xd000-0xd03f mem 0xfebff800-0xfebff9ff,0xfebff400-0xfebff4ff irq 17 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 speaker0: port 0x61 on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: vendor 0x0566 product 0x3002, rev 1.10/1.00, addr 2, iclass 3/1 kbd1 at ukbd0 uhid0: vendor 0x0566 product 0x3002, rev 1.10/1.00, addr 2, iclass 3/1 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 3, iclass 3/1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad2: 57231MB at ata1-master UDMA100 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad2s3a WARNING: attempt to net_add_domain(netgraph) after domainfinalize() sk0: link state changed to DOWN ndis0: link state changed to UP kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x218 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06aa6ae stack pointer = 0x28:0xd4710cac frame pointer = 0x28:0xd4710cd4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 13 (swi4: clock sio) > - Did you add your NDIS driver to /boot/loader.conf, or are you loading > the driver after the system is running multiuser? I'm loading it from /boot/loader.conf > - If you are loading the driver via /boot/loader.conf, did you try > _not_ doing that, and loading it afterwards? No, I didn't. Even if I will do that, why the problem isn't solid? Right now and most of the time I'm happy with this driver loaded at boot time. > - What kind of system is this? Laptop? Desktop? Stone knives and bearskins? It's laptop ASUS L5 Series. > - Is it SMP or UP? SMP. > > When you provide this information, maybe you will get help. > > NOTE: Windows NDIS drivers assume that by the time you intialize them, > the entire OS is up and running, including scheduling and, if present, > multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' > state when it probes/attaches devices, and not all of the scheduling > mechanisms are available yet (for example, you can not msleep() while > cold == 1). This means loading your driver via /boot/loader.conf is > something of a hit-or-miss proposition: sometimes they don't work right, > sometimes they do. To be really safe, you should load them _after_ the > system has come up all the way. > > Unfortunately, it's necessary to initialize the driver briefly in > ndis_attach() in order to find out the device's station address. (You > can only do it via MiniportQueryInformation(), and that only works after > MiniportInitialize() has been called.) When 'ntpdate' is called during boot process, everything is (or should be) initialized I believe. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:15:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 263AB16A420 for ; Thu, 10 Nov 2005 19:15:33 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0FCF43D69 for ; Thu, 10 Nov 2005 19:15:19 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so591834wxc for ; Thu, 10 Nov 2005 11:15:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bBjRBUYX86icvRrcvAG3yfsPJC/a6c6wRcIPftiHouTzRo1ju2seAVSVQIRcGZqOCFzvOBeV0yelTdZNi5GFW4Babnh70B5TMFNnKaDUZ79TrgB07jGLTEfWWXmzCjrahUKCeHehdQslE0CRv74yjLn4wb4Jy1QYIjwz0BUANZM= Received: by 10.70.90.13 with SMTP id n13mr994636wxb; Thu, 10 Nov 2005 11:15:18 -0800 (PST) Received: by 10.70.54.18 with HTTP; Thu, 10 Nov 2005 11:15:18 -0800 (PST) Message-ID: <790a9fff0511101115g6fb6c591l4cac1eadfe8b3245@mail.gmail.com> Date: Thu, 10 Nov 2005 13:15:18 -0600 From: Scot Hetzel To: Eric Anderson In-Reply-To: <59876.10.20.200.100.1131648535.squirrel@10.20.200.100> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> <43734F29.7050101@centtech.com> <790a9fff0511101022i1dc9b00am5575162e7c140da7@mail.gmail.com> <59876.10.20.200.100.1131648535.squirrel@10.20.200.100> Cc: FreeBSD Current Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:15:33 -0000 On 11/10/05, Eric Anderson wrote: > Scot Hetzel said: > >> If there's something I can do to help get some debugging, tell me. > >> Since it's an insta-boot, I'm not sure how to catch that. > >> > > You need to enable the debugging options in your kernel, so that it > > breaks to the debugger instead of rebooting your system. > > Which ones am I missing: > > http://www.googlebit.com/freebsd/kernelconfig.200511100648 > Looks like you have all the required debuggin options. I thought that BREAK_TO_DEBUGGER might have been needed, but according to sys/conf/NOTES it is used when debugging over serial lines. I thought that there might have been a debuggin option that would cause the system to reboot instead of panicing, but I didn't see it in your kernel config. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:30:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 1BB5716A420; Thu, 10 Nov 2005 19:30:44 +0000 (GMT) In-Reply-To: <200511092237.19062.kirk@strauser.com> from Kirk Strauser at "Nov 9, 2005 10:37:14 pm" To: kirk@strauser.com (Kirk Strauser) Date: Thu, 10 Nov 2005 19:30:44 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110193044.1BB5716A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:30:44 -0000 > On Wednesday 09 November 2005 15:23, Charles Swiger wrote: > > > Of course, it's easier to say such things then to write the code, but > > Apple has achieved pretty good results from the IOKit. > > I'm really out of my depth here, but the one thing Apple seems to have > accomplished with IOKit is abysmal performance. When it no longer takes me > four times longer to backup an iMac than a much slower FreeBSD machine with > an older drive, I'll be more impressed with their technology. > -- > Kirk Strauser When Apple was working on the second generation Airport wireless access points, I and a cow-orker ended up taking a trip to the Apple campus to help debug a problem (they were using VxWorks). In some cases it was possible to crash the access point, though you had to flood it with a lot of traffic to do it. The engineer working on the device had a nice Apple laptop in his office which he was using as a traffic monitor and generator to debug the issue. I arrived armed with my trusty Sony VAIO Picturebook, which uses a Transmeta Crusoe TM5600 667Mhz CPU. I'm pretty sure the Apple laptop had way more CPU horsepower than this. Anyway, the engineer there had been trying to use his laptop to generate a flood of traffic to crash the AP (reproducing a crash is the first step to fixing it), but wasn't able to do it very reliably. For the most part, the AP stubbornly refused to die. So I took out my laptop (with FreeBSD 5.2.1, of all things), plugged in my 3Com xl(4) ethernet card, and ran ttcp to generate a stream of UDP traffic. I was able to crash the AP almost right away. Now, I realize that IOKit looks really neat on paper and conceptually has lots of nice advantages, but in practice I think it has performance problems. I'm sure you can get a Mac to saturate a 100Mbps ethernet link with a TCP stream test, but with that test you'll only end up producing about 8000 frames/second, which really doesn't need that much CPU power. It's when you need to generate 80000 or 100000 frames/second that you start running into problems. Also, while code re-use seems like a laudable goal, you have to be careful how you do it. I don't think there's much difference in the amount of code re-use between an IOKit driver and a standard BSD ifnet network driver. Take a look any any given driver, and while the code may appear to share many structural similarities, it's actually quite different, because the underlying hardware is different. You can abstract away certain machine specific things, like DMA and register access (which we do with busdma and bus_space), but you can't easily create common code for DMA descriptor setup, interrupt handling, chip initialization and so on, because all each chip has different descriptor formats, and interrupt signalling/masking mechanisms and initialization procedures. You have to avoid falling into the trap of thinking you can generalize these things just because you may have found one or two cards/chipsets that look kind of the same. There's another issue, which I think has already become a problem with Windows, which is that there's such a thing as insulating driver developers too much from the underlying OS. As was said earlier in this thread, network and storage are probably the most critical types of driver classes. The more network cards and disk controllers you support, the better. For network adapters, Microsoft has the NDIS miniport API. For disks, they have the storport and scsiport miniport APIs. Behind the scenes, these miniport libraries all use the Windows Driver Model (WDM) which encompasses such things as the I/O manager, IRPs and the Plug&Play manager, but those APIs are very complicated and easy to screw up (IRPs especially), so Microsoft recommends using the NDIS, storport or scsiport APIs instead. In fact, I think you're forbidden to stray outside the scsiport/storport API at all if you want to get your driver WHQL certified and signed (the rules are a little less strict with NDIS because you need to use WDM for things like USB network adapters). That's fine and all, but I think what you end up with is developers who know how to use the particular miniport API that concerns them, but who _don't_ know much about the underlying OS in general, which I think is a _bad_ thing. You _want_ to know how the underlying OS works, because that can help you understand why the miniport library layered on top of the other OS facilities does what it does. You can probably get by without that understanding, but if you did, I wouldn't by a NIC with a driver you wrote. :) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:42:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AD0416A41F for ; Thu, 10 Nov 2005 19:42:23 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08ABC43D46 for ; Thu, 10 Nov 2005 19:42:22 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jAAJgLQS093930; Thu, 10 Nov 2005 13:42:21 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jAAJgLNq093929; Thu, 10 Nov 2005 13:42:21 -0600 (CST) (envelope-from tinguely) Date: Thu, 10 Nov 2005 13:42:21 -0600 (CST) From: Mark Tinguely Message-Id: <200511101942.jAAJgLNq093929@casselton.net> To: current@freebsd.org, mcsi@mcsi.pp.ru In-Reply-To: <43737817.8030300@mcsi.pp.ru> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net Cc: wpaul@windriver.com Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:42:23 -0000 We are chasing a different panic (kern/88725) where dynamic callout are freed but the callout could be still pending. The freed memory can be re-allocated, modified and then cause errors when the timer wheel is checked. After finding this one occurance, I did a complete search of callouts, and I see a potential simular error in the ntoskrnl_libfini() routine in the file /sys/compat/ndis/subr_ntoskrnl.c and a few other places (7 total). I wanted to make verify each of these 7 occurances before issuing a patch. I suspect a simple test loop could verify that this is a simular error as kern/88725. --Mark Tinguely From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:43:39 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 6244116A420; Thu, 10 Nov 2005 19:43:39 +0000 (GMT) In-Reply-To: <43739932.6060707@mcsi.pp.ru> from Maxim Maximov at "Nov 10, 2005 10:02:10 pm" To: mcsi@mcsi.pp.ru (Maxim Maximov) Date: Thu, 10 Nov 2005 19:43:39 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110194339.6244116A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@FreeBSD.ORG Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:43:39 -0000 > > If you want us to give you clues, you have to give _US_ clues. > > > > For example, here are some of the things you didn't bother to say: > > > > - _WHICH_ windows driver are you using with NDIS? > > bcmwl5.sys > > > - _WHAT_ wireless card do you have? > > It presents itself as ASUS 802.11g Network Adapter. Based on Broadcom chip. > > > - Complete dmesg output from your system (note: verbose boot is not > > necessary, but _full_ output is necessary, i.e. don't remove things > > you think are unimportant) > > Here it is. > > ndis0: mem 0xfeaf8000-0xfeaf9fff irq 17 > at device 2.0 on pci2 > ndis0: NDIS API version: 5.0 > ndis0: Ethernet address: 00:0e:a6:c2:00:e4 Hm... driver is a little old. I don't think that should matter much though. > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad2s3a > WARNING: attempt to net_add_domain(netgraph) after domainfinalize() This is a little suspicious. > > - Did you add your NDIS driver to /boot/loader.conf, or are you loading > > the driver after the system is running multiuser? > > I'm loading it from /boot/loader.conf I would try not doing that for a while. > > - If you are loading the driver via /boot/loader.conf, did you try > > _not_ doing that, and loading it afterwards? > > No, I didn't. Even if I will do that, why the problem isn't solid? Right > now and most of the time I'm happy with this driver loaded at boot time. I'm not sure. I'm running an SMP system with a Broadcom PCI card and haven't run into this myself. Though that's with 6.0-RELEASE, not -current. (I'm using the same NDIS code that's in -current though.) How often does it crash? > > - What kind of system is this? Laptop? Desktop? Stone knives and bearskins? > > It's laptop ASUS L5 Series. > > > - Is it SMP or UP? > > SMP. It's an SMP laptop? Really? Wow. > > > > When you provide this information, maybe you will get help. > > > > NOTE: Windows NDIS drivers assume that by the time you intialize them, > > the entire OS is up and running, including scheduling and, if present, > > multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' > > state when it probes/attaches devices, and not all of the scheduling > > mechanisms are available yet (for example, you can not msleep() while > > cold == 1). This means loading your driver via /boot/loader.conf is > > something of a hit-or-miss proposition: sometimes they don't work right, > > sometimes they do. To be really safe, you should load them _after_ the > > system has come up all the way. > > > > Unfortunately, it's necessary to initialize the driver briefly in > > ndis_attach() in order to find out the device's station address. (You > > can only do it via MiniportQueryInformation(), and that only works after > > MiniportInitialize() has been called.) > > When 'ntpdate' is called during boot process, everything is (or should > be) initialized I believe. Yes, but MiniportInitialize() has already been called once while cold == 1. What I'm saying is you have to avoid doing that entirely. Try doing it by loading bcmwl5_sys.ko after the system has gone multiuser. If the problem persists, then I'm just full of crap (wouldn't be the first time) and there's something else going wrong, but I think it bears investigating. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:46:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6411B16A420 for ; Thu, 10 Nov 2005 19:46:26 +0000 (GMT) (envelope-from lreid@cs.okstate.edu) Received: from csa.cs.okstate.edu (a.cs.okstate.edu [139.78.113.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F08A43D4C for ; Thu, 10 Nov 2005 19:46:25 +0000 (GMT) (envelope-from lreid@cs.okstate.edu) Received: from [192.168.220.32] (unknown [164.58.79.195]) by csa.cs.okstate.edu (Postfix) with ESMTP id 662CFA062E for ; Thu, 10 Nov 2005 13:46:25 -0600 (CST) Message-ID: <4373A384.2020605@cs.okstate.edu> Date: Thu, 10 Nov 2005 13:46:12 -0600 From: Reid Linnemann User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051005) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109093920.GA45506@samodelkin.net> <20051109110903.583bb72d.lists@yazzy.org> In-Reply-To: <20051109110903.583bb72d.lists@yazzy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:46:26 -0000 Marcin Jessa wrote: > > Sure, but the point is to use native FreeBSD drivers, even if they were > in closed source binary form and not drivers written for an entirely > different O.S. > > Marcin I'd like to pose my own semi-educated opinion about this topic: If hardware vendors are given the ability to provide closed-source, unfree-licensed binary drivers for hardware, they will probably gladly do so. They get the bonus of sales to FreeBSD users without having to give up control or knowledge of their products. I can see the potential that with those benefits in mind, eventually no vendors would opt to support the open implementations of drivers for their products, instead placating users only with binary drivers which are subject to non-berkeley licensing and that - being that no source is provided to FreeBSD - will be unsupportable by the FreeBSD project itself. Users could be inandated with license agreements and use policies, and their FreeBSD systems be held at the mercy of miserable 3rd party support. Maybe this isn't even a remote possibility, I'm not involved in release engineering at all and I definitely am not a soure of authority on this issue, but the mere thought of this situation makes me shudder. I just do not want to see FreeBSD no longer be free (as in speech) through a dependency on restricted binary drivers. I'm not saying kernel interfaces shouldn't be stabilized to promote compatibility, but I am saying that caution should be used lest FreeBSD eventually be mangled and twisted into 'EULABSD'. Anyway, that's my half-educated opinion. If it's wrong, fantastic! I can sleep better at night. -- Reid Linnemann Senior Systems Analyst Oklahoma Department of CareerTech 405-743-5422 rlinn@okcareertech.org -Ars longa, vita brevis- From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 21:12:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFE6816A41F for ; Thu, 10 Nov 2005 21:12:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D03643D48 for ; Thu, 10 Nov 2005 21:12:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1722122 for multiple; Thu, 10 Nov 2005 16:14:51 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAALCTwA069693; Thu, 10 Nov 2005 16:12:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 10 Nov 2005 16:02:12 -0500 User-Agent: KMail/1.8.2 References: <20051108232855.2d1b7df5.lists@yazzy.org> <20051109110903.583bb72d.lists@yazzy.org> <4373A384.2020605@cs.okstate.edu> In-Reply-To: <4373A384.2020605@cs.okstate.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101602.13740.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Reid Linnemann Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 21:12:46 -0000 On Thursday 10 November 2005 02:46 pm, Reid Linnemann wrote: > Marcin Jessa wrote: > > Sure, but the point is to use native FreeBSD drivers, even if they were > > in closed source binary form and not drivers written for an entirely > > different O.S. > > > > Marcin > > I'd like to pose my own semi-educated opinion about this topic: > > If hardware vendors are given the ability to provide closed-source, > unfree-licensed binary drivers for hardware, they will probably gladly > do so. They get the bonus of sales to FreeBSD users without having to > give up control or knowledge of their products. They already have the ability to do that and for the most part they don't. Nvidia and Atheros are two companies that do. I think what you are missing here is that regardless of a stable API, having to pay an engineer to learn about that API and the whole "feel" of a given OS and then write and support a driver is not worth the potential FreeBSD sales to most companies. They are only going to provide a driver if they feel they can turn a worthwhile profit doing it, not out of the goodness of their hearts. Currently they can support a rather large chunk of market share if they provide drivers for Windoze, Linux, and maybe OS X. FreeBSD's market share for most folks is just not comparable to those three, so they do not see it as being worth the investment. -- 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 Nov 10 21:20:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36A1816A41F for ; Thu, 10 Nov 2005 21:20:19 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from upchuck.ugcs.caltech.edu (upchuck.ugcs.caltech.edu [131.215.176.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DCB143D48 for ; Thu, 10 Nov 2005 21:20:18 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by upchuck.ugcs.caltech.edu (Postfix, from userid 3640) id 02060AC440; Thu, 10 Nov 2005 13:20:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by upchuck.ugcs.caltech.edu (Postfix) with ESMTP id E1361AC43C; Thu, 10 Nov 2005 13:20:17 -0800 (PST) Date: Thu, 10 Nov 2005 13:20:17 -0800 (PST) From: Jon Dama To: Scott Long In-Reply-To: <43725294.2010905@samsco.org> Message-ID: References: <43723F49.9010109@ultra-secure.de> <43725294.2010905@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, Rainer Duffner Subject: Re: 6.0 panics with 3GB and 4GB RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 21:20:19 -0000 Check your memory loadings. e.g., on steppings CG or older, an opteron could only support 6 "loads" at DDR400. Most 1GB floating around are actually double load sticks, therefore 1GBx4 = 8 loads = out-of-spec. Many motherboards read off from the DRAM itself that it supports DDR400 and switch into that mode without considering that the processor needs the memory to be throttled down to DDR333. Otherwise, test your setup with memtest64. Experience has shown that if you built your system from parts about 1 in 20 memory sticks will have a defect that will be picked up by memtest64 (but which you otherwise might never notice for a while, esp if you aren't using ECC memory). Systems that are professionally integrated tend to fair much better; either because they test their memory or just managed to get more trustworthy supplies of it by not being as price sensitive. I had big issues with 5.3 4GB+ but these are definitely resolved. Now if you want to complain about how programs running in linux32 emulation can panic the kernel, I'm with you. :-) On Wed, 9 Nov 2005, Scott Long wrote: > Rainer Duffner wrote: > > Hello, > > > > this is on a dual 1.2 GHz Supermicro P3TDE6 board. > > > > Sorry, I can't provide more details, just wanted to let you know. > > I have little time, so I just removed the RAM. The machine is fine with > > 1 or 2 GB RAM. > > > > > > cheers, > > Rainer > > Can't help you without more details. I regularly run with 4-8GB of RAM > without any problems whatsoever. > > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 23:17:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 391D916A41F; Thu, 10 Nov 2005 23:17:14 +0000 (GMT) (envelope-from jr@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8054843D45; Thu, 10 Nov 2005 23:17:13 +0000 (GMT) (envelope-from jr@opal.com) Received: from linwhf.opal.com (118.79.171.66.subscriber.vzavenue.net [66.171.79.118]) by smtp.vzavenue.net (MOS 3.7.1-GA) with ESMTP id DHE09343; Thu, 10 Nov 2005 18:16:49 -0500 (EST) Received: from ASSP-nospam (localhost [127.0.0.1]) by linwhf.opal.com (8.13.4/8.13.4) with ESMTP id jAANGm1V001287; Thu, 10 Nov 2005 18:16:48 -0500 (EST) (envelope-from jr@opal.com) Received: from 127.0.0.1 ([127.0.0.1] helo=linwhf.opal.com) by ASSP-nospam ; 10 Nov 05 23:16:48 -0000 Received: (from jr@localhost) by linwhf.opal.com (8.13.4/8.13.4/Submit) id jAANGmiK001286; Thu, 10 Nov 2005 18:16:48 -0500 (EST) (envelope-from jr) Date: Thu, 10 Nov 2005 18:16:47 -0500 From: "J.R. Oldroyd" To: Sean McNeil Message-ID: <20051110231647.GA1172@linwhf.opal.com> References: <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> <1131591746.24065.3.camel@triton.mcneil.com> <1131643130.1444.2.camel@triton.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131643130.1444.2.camel@triton.mcneil.com> User-Agent: Mutt/1.4.2.1i X-Junkmail-Status: score=0/50, host=smtp.vzavenue.net Cc: ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 23:17:14 -0000 On Nov 10, 09:18, Sean McNeil wrote: > On Thu, 2005-11-10 at 07:34 -0800, SUZUKI Shinsuke wrote: > > > > I think I've found the problem. > > Could you please try the following patch? > > > > If it's okay, I'll commit and MFC it. > > The patch does indeed allow me to put my revpath check back in ipfw. > No change here. But that patch was for ipfw2. I am using pf. Is a similar patch needed for pf? -jr From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 23:28:06 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2BA216A41F; Thu, 10 Nov 2005 23:28:06 +0000 (GMT) (envelope-from pckizer@nostrum.com) Received: from nostrum.com (magus.nostrum.com [69.5.195.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22ED943D46; Thu, 10 Nov 2005 23:28:05 +0000 (GMT) (envelope-from pckizer@nostrum.com) Received: from [165.91.250.64] (magus.tamu.edu [165.91.250.64]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAANS4ao094624 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 10 Nov 2005 17:28:05 -0600 (CST) (envelope-from pckizer@nostrum.com) In-Reply-To: <20051110154950.Q68007@fledge.watson.org> References: <200510191623.j9JGNSfr007356@magus.nostrum.com> <20051019175020.S60849@fledge.watson.org> <20051025110453.L6720@fledge.watson.org> <2E18CEAE-2A72-4387-B92E-DAED7CC7FACD@nostrum.com> <33E53AA7-2A01-4BBE-9674-8F54E008D0A8@nostrum.com> <0906B09C-B5A2-402E-BF39-57EBB20B2D4F@nostrum.com> <425C901E-3315-41EC-B2D9-C372A2110FF0@nostrum.com> <20051109184311.Y85371@fledge.watson.org> <20051110154950.Q68007@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13D42742-8D19-4FD0-8249-64A64C55A5D8@nostrum.com> Content-Transfer-Encoding: 7bit From: Philip Kizer Date: Thu, 10 Nov 2005 17:28:03 -0600 To: freebsd-current@FreeBSD.org X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 165.91.250.64 is authenticated by a trusted mechanism) Cc: Robert Watson Subject: Re: Problem remains with FreeBSD 6.0-RELEASE as seen in RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 23:28:06 -0000 On Nov 10, 2005, at 09:54, Robert Watson wrote: > Last night I successfully sent this patch to the wrong person, as > I'm chasing a number of different bugs currently. While it won't > help with his quota-related problems, using a combination of > patches (attached) I'm now able to run a set of file descriptor > passing edge case regression tests successfully. I've committed > the regression test to src/tools/regression/sockets/unix_passfd. > This test should only be run once the patches are applied, needless > to say. *chuckle* No worries... > If you could try out the patches and let me know if things improve, > that would be great. Patches applied and running now. You can be sure I'll let you know as soon as I have new info (although if your first go is all good, for my production situation, it's the old "proving a negative" problem and we'll be good if I hit my personal timeout next week and mail you back to say I haven't seen a repeat). Thanks! Philip From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 23:53:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75F7516A41F for ; Thu, 10 Nov 2005 23:53:29 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA08143D48 for ; Thu, 10 Nov 2005 23:53:28 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jAANrMA2047535; Thu, 10 Nov 2005 15:53:22 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jAANrLs7047534; Thu, 10 Nov 2005 15:53:21 -0800 (PST) (envelope-from jmg) Date: Thu, 10 Nov 2005 15:53:21 -0800 From: John-Mark Gurney To: Scot Hetzel Message-ID: <20051110235321.GD775@funkthat.com> Mail-Followup-To: Scot Hetzel , Eric Anderson , FreeBSD Current References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> <43734F29.7050101@centtech.com> <790a9fff0511101022i1dc9b00am5575162e7c140da7@mail.gmail.com> <59876.10.20.200.100.1131648535.squirrel@10.20.200.100> <790a9fff0511101115g6fb6c591l4cac1eadfe8b3245@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0511101115g6fb6c591l4cac1eadfe8b3245@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 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 , Eric Anderson Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Nov 2005 23:53:29 -0000 Scot Hetzel wrote this message on Thu, Nov 10, 2005 at 13:15 -0600: > I thought that there might have been a debuggin option that would > cause the system to reboot instead of panicing, but I didn't see it in > your kernel config. The option is KDB_UNATTENDED which will wait for input on the console for a few seconds before rebooting... If you hit a key, it'll drop into the debugger... -- 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 Nov 11 03:15:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02E9F16A41F for ; Fri, 11 Nov 2005 03:15:37 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73B8443D46 for ; Fri, 11 Nov 2005 03:15:36 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 35834279 for ; Thu, 10 Nov 2005 20:24:43 -0700 Date: Thu, 10 Nov 2005 21:21:48 -0600 From: Vulpes Velox To: freebsd-current@freebsd.org Message-ID: <20051110212148.7a335fd9@vixen42.vulpes> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-NotAscii: charset=us-ascii X-IP-stats: Incoming Last 1, First 39, in=64, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Subject: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 03:15:37 -0000 Ran into a few problems with ndisgen today. I have to edit every instance of the following out to get it to convert. Magic Packet = "Magic Packet" Pattern Match = "Pattern Match" Mag Pack Patt Match = "Magic Packet & Pattern Match" Link Change = "Link Change" Upon loading the driver I get... no match for ExUnregisterCallback no match for ZwPowerInformation no match for ExRegisterCallback no match for ExCreateCallback no match for ZwUnmapViewOfSection no match for ZwMapViewOfSection no match for ZwOpenSection no match for wcslen Any chance of getting this working or any suggestions? From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 17:18:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F0B116A41F; Thu, 10 Nov 2005 17:18:57 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8459E43D55; Thu, 10 Nov 2005 17:18:53 +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 CA7A6F24F4; Thu, 10 Nov 2005 09:18:52 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00821-01; Thu, 10 Nov 2005 09:18:51 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 3B3CAF1AF2; Thu, 10 Nov 2005 09:18:51 -0800 (PST) From: Sean McNeil To: SUZUKI Shinsuke In-Reply-To: References: <1131161768.8571.9.camel@server.mcneil.com> <8427EC93-6788-4659-B769-3703FF2AAA9A@mcneil.com> <1131359967.1874.6.camel@server.mcneil.com> <1131424479.1341.3.camel@server.mcneil.com> <20051110024941.GA987@linwhf.opal.com> <1131591746.24065.3.camel@triton.mcneil.com> Content-Type: text/plain Date: Thu, 10 Nov 2005 09:18:50 -0800 Message-Id: <1131643130.1444.2.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Fri, 11 Nov 2005 03:21:57 +0000 Cc: jr@opal.com, ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 17:18:57 -0000 On Thu, 2005-11-10 at 07:34 -0800, SUZUKI Shinsuke wrote: > Hi, > > >>>>> On Wed, 09 Nov 2005 19:12:58 -0800 > >>>>> suz@freebsd.org(SUZUKI Shinsuke) said: > > > Oh Boy! This is very interesting. I took a look at my ipfw show during > > a ping6 and see the problem. The revpath is messed up. I took out my > > rule: > > add deny all from any to any not verrevpath in via dc0 > > and ping6 now works. > suz> I'll check it from this point of view. > > I think I've found the problem. > Could you please try the following patch? > > If it's okay, I'll commit and MFC it. The patch does indeed allow me to put my revpath check back in ipfw. Thank you so much for all your hard work! Cheers, Sean > ----- > Index: ip_fw2.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v > retrieving revision 1.106.2.4 > diff -u -r1.106.2.4 ip_fw2.c > --- ip_fw2.c 4 Nov 2005 20:26:14 -0000 1.106.2.4 > +++ ip_fw2.c 10 Nov 2005 14:44:06 -0000 > @@ -639,8 +639,14 @@ > if (ro.ro_rt == NULL) > return 0; > > - /* if ifp is provided, check for equality with rtentry */ > - if (ifp != NULL && ro.ro_rt->rt_ifp != ifp) { > + /* > + * if ifp is provided, check for equality with rtentry > + * We should use rt->rt_ifa->ifa_ifp, instead of rt->rt_ifp, > + * to support the case of sending packets to an address of our own. > + * (where the former interface is the first argument of if_simloop() > + * (=ifp), the latter is lo0) > + */ > + if (ifp != NULL && ro.ro_rt->rt_ifa->ifa_ifp != ifp) { > RTFREE(ro.ro_rt); > return 0; > } > From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:59:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D46B16A41F for ; Thu, 10 Nov 2005 19:59:05 +0000 (GMT) (envelope-from wpaul@windriver.com) Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 031F043D5A for ; Thu, 10 Nov 2005 19:59:04 +0000 (GMT) (envelope-from wpaul@windriver.com) Received: from huisne.wrs.com (huisne [147.11.46.60]) by mail.wrs.com (8.13.3/8.13.3) with ESMTP id jAAJwohI021463; Thu, 10 Nov 2005 11:58:50 -0800 (PST) Received: from unknown-46-211 (IDENT:U2FsdGVkX19EdtwcTl5ENIPgqCoh+GZqxcMm7mJf5eY@[147.11.46.211]) by huisne.wrs.com (8.9.1/8.9.0) with ESMTP id LAA15924; Thu, 10 Nov 2005 11:58:49 -0800 (PST) From: Bill Paul Organization: Wind River Systems To: Mark Tinguely , current@freebsd.org, mcsi@mcsi.pp.ru Date: Thu, 10 Nov 2005 11:58:48 -0800 User-Agent: KMail/1.5.3 References: <200511101942.jAAJgLNq093929@casselton.net> In-Reply-To: <200511101942.jAAJgLNq093929@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101158.48784.wpaul@windriver.com> X-Mailman-Approved-At: Fri, 11 Nov 2005 03:23:41 +0000 Cc: Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Nov 2005 19:59:05 -0000 Of all the gin joints in all the towns in all the world, Mark Tinguely had to walk into mine and say: > We are chasing a different panic (kern/88725) where dynamic callout > are freed but the callout could be still pending. The freed memory > can be re-allocated, modified and then cause errors when the timer > wheel is checked. > > After finding this one occurance, I did a complete search of callouts, > and I see a potential simular error in the ntoskrnl_libfini() routine > in the file /sys/compat/ndis/subr_ntoskrnl.c and a few other places > (7 total). I wanted to make verify each of these 7 occurances before > issuing a patch. > > I suspect a simple test loop could verify that this is a simular error > as kern/88725. > > --Mark Tinguely Hm. Unfortunately, the ntoskrnl_libfini() won't be called until the ndis.ko module is unloaded, and that's not happening here. That isn't to say that there isn't a callout bug in there somewhere. Note that Project Evil has its own callwheel because struct callout doesn't fit inside the Windows struct KTIMER (and in Windows, drivers allocate KTIMERs themselves from the heap and can free them without calling any routine to deallocate them first). The assumption is that by the time MiniportHalt() has completed, the underlying driver has stopped/cancelled all the timers it started. Originally I used the timeout()/untimeout() API, but I found that in some cases I would find myself trying to cancel a timer that had already fired. This problem doesn't occur with the built-in callwheel that's there now. Also, using timeout()/untimeout() causes timer callouts to be run with Giant held, which I didn't want. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "Ignorance may be bliss, but delusion is ecstasy!" -Perki ============================================================================= From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 05:34:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id DD46D16A420; Fri, 11 Nov 2005 05:34:38 +0000 (GMT) In-Reply-To: <20051110212148.7a335fd9@vixen42.vulpes> from Vulpes Velox at "Nov 10, 2005 09:21:48 pm" To: v.velox@vvelox.net (Vulpes Velox) Date: Fri, 11 Nov 2005 05:34:38 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051111053438.DD46D16A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 05:34:39 -0000 > Ran into a few problems with ndisgen today. > > I have to edit every instance of the following out to get it to > convert. > Magic Packet = "Magic Packet" > Pattern Match = "Pattern Match" > Mag Pack Patt Match = "Magic Packet & Pattern Match" > Link Change = "Link Change" > > > Upon loading the driver I get... > no match for ExUnregisterCallback > no match for ZwPowerInformation > no match for ExRegisterCallback > no match for ExCreateCallback > no match for ZwUnmapViewOfSection > no match for ZwMapViewOfSection > no match for ZwOpenSection > no match for wcslen > > Any chance of getting this working or any suggestions? There's no chance of you getting _anything_ until such time as you tell us _WHAT_ driver you're trying to convert, and _WHAT_ card it's for. I want you to explain to me in precise detail why you thought it was acceptable to post this message without bothering to provide this information. Come on people, why are you making this so hard. You don't just jump in and say "I have a problem." What you're _supposed_ to do is say "I have , I tried to do , and I observed ," there , and are spelled out in very clear and complete detail. You chose to leave out the "I have " part. You chose poorly. It looks an awful lot like you're trying to convert a driver that isn't for Windows 2000 or Windows XP. It might be for Win98. Of course it might also not even be an NDIS driver. There's no way to know until you provide more information. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 05:42:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 17ED516A421; Fri, 11 Nov 2005 05:42:07 +0000 (GMT) In-Reply-To: <20051110212148.7a335fd9@vixen42.vulpes> from Vulpes Velox at "Nov 10, 2005 09:21:48 pm" To: v.velox@vvelox.net (Vulpes Velox) Date: Fri, 11 Nov 2005 05:42:07 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051111054207.17ED516A421@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 05:42:07 -0000 > Ran into a few problems with ndisgen today. > > I have to edit every instance of the following out to get it to > convert. > Magic Packet = "Magic Packet" > Pattern Match = "Pattern Match" > Mag Pack Patt Match = "Magic Packet & Pattern Match" > Link Change = "Link Change" > > > Upon loading the driver I get... > no match for ExUnregisterCallback > no match for ZwPowerInformation > no match for ExRegisterCallback > no match for ExCreateCallback > no match for ZwUnmapViewOfSection > no match for ZwMapViewOfSection > no match for ZwOpenSection > no match for wcslen > > Any chance of getting this working or any suggestions? > Ok, had I read the subject line of your mail fully I'd have known what driver it was. I'm a dolt and I've clearly had too long of a day. Here are the problems: - I don't know exactly what driver image you have. Unless you provide the URL for where you got it to put a copy somewhere, I can't really analyze it. - The .inf parser is not perfect. It's actually much stricter about syntax than Windows is. Stuff that works ok for Windows may be flagged as a syntax error by ndiscvt. If someone wants to help fix this, they're welcome to. (No kernel hacking required.) - I have no earthy idea why Marvell is referencing these functions in their driver. They're totally outside the NDIS spec. I'd be rather surprised that such a driver was able to get WHQL certification. (Assuming it did.) - This is Marvell. Given the rotten treatment I've had from them in the past, I'm not inclined to do them any favors now, so I'm not exactly inclined to fix this anytime soon. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 06:25:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2C2D16A41F for ; Fri, 11 Nov 2005 06:25:38 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4552D43D45 for ; Fri, 11 Nov 2005 06:25:38 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so471155wxc for ; Thu, 10 Nov 2005 22:25:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=BHBRJ1JmK2z78cJe8jBiXITn4QB1LwJQaDu0xBUC0V9b45mOhRc/8YnxJISGsBB0ab6w2t/ZF+0F+eeIVUGbZqC9YirZueab7/iaoX+GcbLBb9J2KJN5hMSBb7cEIzjHO49juNq3fvUP5J6Ebn0rwPCUk7Z62GLZdm5jV8rJnAg= Received: by 10.70.40.11 with SMTP id n11mr1821536wxn; Thu, 10 Nov 2005 22:25:37 -0800 (PST) Received: by 10.70.9.2 with HTTP; Thu, 10 Nov 2005 22:25:37 -0800 (PST) Message-ID: <47d0403c0511102225m1d48e5f8yd5da241e069dcfe8@mail.gmail.com> Date: Fri, 11 Nov 2005 06:25:37 +0000 From: Ben Kaduk To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kldxref error in make installkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 06:25:38 -0000 Hi all -- sorry if I missed some note about this, but I'm trying to update from FreeBSD prolepsis.urh.uiuc.edu 7.0-CURRENTFreeBSD 7.0-CURRENT #0: Tue Oct 11 18:45:49 UTC 2005 kaduk@prolepsis.urh.uiuc.edu:/usr/obj/usr/src/sys/GENERIC i386 to a -current supped at 22:28:34 central time (US). Buildworld goes fine, but 'make kernel KERNCONF=3DPROLEPSIS' gives me some suprising output after installing modules, shown here [snip] =3D=3D=3D> xe (install) install -o root -g wheel -m 555 if_xe.ko /boot/kernel install -o root -g wheel -m 555 if_xe.ko.symbols /boot/kernel =3D=3D=3D> xl (install) install -o root -g wheel -m 555 if_xl.ko /boot/kernel install -o root -g wheel -m 555 if_xl.ko.symbols /boot/kernel kldxref /boot/kernel kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked [snip] with many more copies of the last message (the same as the number of modules, perhaps?). Has anyone else seen this, and should I be worried abou= t it? Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 08:19:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3777016A41F for ; Fri, 11 Nov 2005 08:19:17 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C4D43D49 for ; Fri, 11 Nov 2005 08:19:16 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jAB8JEAe080837; Fri, 11 Nov 2005 10:19:14 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 84852-03-3; Fri, 11 Nov 2005 10:19:12 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jAB8FYEx080711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 10:15:34 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jAB8FebX099728; Fri, 11 Nov 2005 10:15:41 +0200 (EET) (envelope-from ru) Date: Fri, 11 Nov 2005 10:15:40 +0200 From: Ruslan Ermilov To: Ben Kaduk Message-ID: <20051111081540.GB87446@ip.net.ua> References: <47d0403c0511102225m1d48e5f8yd5da241e069dcfe8@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <47d0403c0511102225m1d48e5f8yd5da241e069dcfe8@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@freebsd.org Subject: Re: kldxref error in make installkernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 08:19:17 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2005 at 06:25:37AM +0000, Ben Kaduk wrote: > Hi all -- sorry if I missed some note about this, but I'm trying to update > from > FreeBSD prolepsis.urh.uiuc.edu > 7.0-CURRENTFreeBSD > 7.0-CURRENT #0: Tue Oct 11 18:45:49 UTC 2005 > kaduk@prolepsis.urh.uiuc.edu:/usr/obj/usr/src/sys/GENERIC > i386 > to a -current supped at 22:28:34 central time (US). >=20 > Buildworld goes fine, but 'make kernel KERNCONF=3DPROLEPSIS' gives me some > suprising output after installing modules, shown here > [snip] > =3D=3D=3D> xe (install) > install -o root -g wheel -m 555 if_xe.ko /boot/kernel > install -o root -g wheel -m 555 if_xe.ko.symbols /boot/kernel > =3D=3D=3D> xl (install) > install -o root -g wheel -m 555 if_xl.ko /boot/kernel > install -o root -g wheel -m 555 if_xl.ko.symbols /boot/kernel > kldxref /boot/kernel > kldxref: file isn't dynamically-linked > kldxref: file isn't dynamically-linked > kldxref: file isn't dynamically-linked > kldxref: file isn't dynamically-linked > [snip] >=20 > with many more copies of the last message (the same as the number of > modules, perhaps?). Has anyone else seen this, and should I be worried ab= out > it? >=20 They are harmless, you shouldn't be worried. I've just committed a bandaid for this to kldxref(8) that skips .symbols files. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDdFMsqRfpzJluFF4RApzzAJ9x+USYspqRQhiBFKKzti2dfL3FAgCeOgmb YzXboh8aetSNUiPDdxHxIGk= =VxGV -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 09:09:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70D8F16A41F; Fri, 11 Nov 2005 09:09:54 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D398B43D45; Fri, 11 Nov 2005 09:09:51 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029333.msg; Fri, 11 Nov 2005 15:09:42 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127198, updated: 10.11.2005] To: John Baldwin References: <200511101140.15374.jhb@freebsd.org> From: Victor Snezhko Date: Fri, 11 Nov 2005 15:09:36 +0600 In-Reply-To: <200511101140.15374.jhb@freebsd.org> (John Baldwin's message of "Thu, 10 Nov 2005 11:40:13 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Fri, 11 Nov 2005 15:09:42 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: max@love2party.net, freebsd-current@freebsd.org, snezhko@indorsoft.ru, bug-followup@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 09:09:54 -0000 John Baldwin writes: >>> Mark Tinguely has found the offending timer. >>> The following patch fixes the problem for me: >> >> Thanks. sounds right for me. >> So please commit it if when you've finished the test with fresh -current. > > As a general rule you should be using callout_drain() before freeing a callout > to handle the race condition where the callout is running on another CPU (so > callout_stop can't stop it) while you are freeing it. Note that you can not > use callout_drain() if you are holding any locks, though. In those cases you > will need to defer the callout_drain() and free() until you have dropped the > locks. Here's one example fix: > > Index: nd6.c > =================================================================== > RCS file: /usr/cvs/src/sys/netinet6/nd6.c,v > retrieving revision 1.62 > diff -u -r1.62 nd6.c > --- nd6.c 22 Oct 2005 05:07:16 -0000 1.62 > +++ nd6.c 3 Nov 2005 19:56:42 -0000 > @@ -398,7 +398,7 @@ > if (tick < 0) { > ln->ln_expire = 0; > ln->ln_ntick = 0; > - callout_stop(&ln->ln_timer_ch); > + callout_drain(&ln->ln_timer_ch); > } else { > ln->ln_expire = time_second + tick / hz; > if (tick > INT_MAX) { The code that was committed (and introduced armed timer that was freed) is full of callout_stops and contains not a single callout_drain. So I think in order to be consistent we shouldn't fix two problems at once. The right way would be to commit the fix with callout stop at first (and close the PR) and then investigate whether we can replace stops with drains without introducing a deadlock (for each timer separately). In this case we will at least have a working system to cvsdown to it if there will be issues with callout_drain. I have tested the patch by Mark Tinguely (that fixes mld6.c) on the fresh -current (cvsupped ~2 days ago), it works there too (unsurprisingly). So it may be committed, I suppose (without the debug printf, of course). -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 09:12:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3F9F16A41F for ; Fri, 11 Nov 2005 09:12:50 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E28643D5A for ; Fri, 11 Nov 2005 09:12:49 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1EaUxj-0001Mi-42; Fri, 11 Nov 2005 11:12:47 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: John-Mark Gurney In-reply-to: Your message of Thu, 10 Nov 2005 15:53:21 -0800 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Nov 2005 11:12:47 +0200 From: Danny Braniss Message-ID: Cc: FreeBSD Current , Eric Anderson Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 09:12:50 -0000 > Scot Hetzel wrote this message on Thu, Nov 10, 2005 at 13:15 -0600: > > I thought that there might have been a debuggin option that would > > cause the system to reboot instead of panicing, but I didn't see it in > > your kernel config. > > The option is KDB_UNATTENDED which will wait for input on the console > for a few seconds before rebooting... If you hit a key, it'll drop > into the debugger... or sysctl debug.debugger_on_panic="0" but somehow this does not work :-( danny > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Nov 11 09:50:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D27816A420 for ; Fri, 11 Nov 2005 09:50:28 +0000 (GMT) (envelope-from keramida@hellug.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7744A43D46 for ; Fri, 11 Nov 2005 09:50:27 +0000 (GMT) (envelope-from keramida@hellug.gr) Received: from flame.pc (adsl-66-124-231-46.dsl.snfc21.pacbell.net [66.124.231.46]) (authenticated bits=0) by igloo.linux.gr (8.13.4/8.13.4/Debian-3) with ESMTP id jAB9jIZb028017; Fri, 11 Nov 2005 11:45:24 +0200 Received: by flame.pc (Postfix, from userid 1001) id 9786A116A7; Fri, 11 Nov 2005 01:45:08 -0800 (PST) Date: Fri, 11 Nov 2005 01:45:08 -0800 From: Giorgos Keramidas To: Eric Anderson Message-ID: <20051111094508.GA2945@flame.pc> References: <43724C11.5090201@centtech.com> <20051110081736.GA1855@flame.pc> <43734F29.7050101@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43734F29.7050101@centtech.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.499, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.90, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@linux.gr X-Mailman-Approved-At: Fri, 11 Nov 2005 12:28:33 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Instant reboot on new interface coming up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 09:50:28 -0000 On 2005-11-10 07:46, Eric Anderson wrote: >Giorgos Keramidas wrote: >>On 2005-11-09 13:20, Eric Anderson wrote: >>> I've been having issues lately when trying to bring up a new >>> interface. It's a hard problem to actually see, because it makes my >>> machine instantly reboot. >>> [...] >>> I'm running 7.0-CURRENT as of a few days ago. >> >> How many days? You need at least a version that includes the following >> commit, otherwise you may have problems with ACPI or mbuf allocation: >> >> % glebius 2005-11-06 16:47:59 UTC >> % >> % FreeBSD src repository >> % >> % Modified files: >> % sys/kern kern_mbuf.c >> % Log: >> % Fix panic string in last revision. >> % >> % Revision Changes Path >> % 1.15 +1 -1 src/sys/kern/kern_mbuf.c > > As of Monday, Nov 7th, and I've just checked, and I am indeed using > this later version. It happened both before, and after this commit. Hi Eric, There are reports for callout list corruption in recent CURRENT, after some changes to IPv6 code. If you don't really depend to INET6, can you disable that in your kernel config and see if the panics go away? - Giorgos From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:21:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A15B16A41F; Fri, 11 Nov 2005 16:21:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A65D43D46; Fri, 11 Nov 2005 16:21:52 +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.4/8.13.4) with ESMTP id jABGLpIc018846; Fri, 11 Nov 2005 11:21:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jABGLpqj099278; Fri, 11 Nov 2005 11:21:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A87987302F; Fri, 11 Nov 2005 11:21:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051111162151.A87987302F@freebsd-current.sentex.ca> Date: Fri, 11 Nov 2005 11:21:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 16:21:53 -0000 TB --- 2005-11-11 15:44:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-11 15:44:25 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-11-11 15:44:25 - cleaning the object tree TB --- 2005-11-11 15:45:04 - checking out the source tree TB --- 2005-11-11 15:45:04 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-11-11 15:45:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-11 15:51:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-11 15:51:49 - cd /src TB --- 2005-11-11 15:51:49 - /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 [...] rm -f .depend mkdep -f .depend -a /src/games/grdc/grdc.c echo grdc: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libncurses.a >> .depend ===> games/morse (depend) rm -f .depend mkdep -f .depend -a -DSPEAKER=\"/dev/speaker\" /src/games/morse/morse.c /src/games/morse/morse.c:67:33: dev/speaker/speaker.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/games/morse. *** Error code 1 Stop in /src/games. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-11 16:21:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-11 16:21:51 - ERROR: failed to build world TB --- 2005-11-11 16:21:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:30:14 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 026C416A45F; Fri, 11 Nov 2005 16:30:13 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from portpc-design.spb.ru (portpc-design.spb.ru [81.176.64.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF0D743D49; Fri, 11 Nov 2005 16:30:11 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [85.140.159.13] (ppp85-140-159-13.pppoe.mtu-net.ru [85.140.159.13]) (authenticated bits=0) by portpc-design.spb.ru (8.13.5/8.13.5) with ESMTP id jABGU5Le009165; Fri, 11 Nov 2005 19:30:07 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4374C705.6070908@mcsi.pp.ru> Date: Fri, 11 Nov 2005 19:29:57 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051109 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Bill Paul References: <20051110194339.6244116A420@hub.freebsd.org> In-Reply-To: <20051110194339.6244116A420@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on 81.176.64.226 X-Virus-Status: Clean Cc: current@FreeBSD.ORG Subject: Re: CURRENT panics sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 16:30:14 -0000 Bill Paul wrote: >> >>Here it is. >> >>ndis0: mem 0xfeaf8000-0xfeaf9fff irq 17 >>at device 2.0 on pci2 >>ndis0: NDIS API version: 5.0 >>ndis0: Ethernet address: 00:0e:a6:c2:00:e4 > > > Hm... driver is a little old. I don't think that should matter much though. They don't have a new one on their download page :( > > >>SMP: AP CPU #1 Launched! >>Trying to mount root from ufs:/dev/ad2s3a >>WARNING: attempt to net_add_domain(netgraph) after domainfinalize() > > > This is a little suspicious. This lasts for a long time already. This issue is known and harmless, as someone said. > > >>>- Did you add your NDIS driver to /boot/loader.conf, or are you loading >>> the driver after the system is running multiuser? >> >>I'm loading it from /boot/loader.conf > > > I would try not doing that for a while. OK, now I don't. First (and only for now) boot is successful. But I noticed, that my /etc/start_if.ndis0 which loads *.ko has been running twice during boot phase. I wonder can this be a reason somehow? # rcorder /etc/rc.d/* > /dev/null rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/newsyslog'. rcorder: Circular dependency on provision `mountcritremote' in file `/etc/rc.d/syslogd'. Exit 1 > > >>>- If you are loading the driver via /boot/loader.conf, did you try >>> _not_ doing that, and loading it afterwards? >> >>No, I didn't. Even if I will do that, why the problem isn't solid? Right >>now and most of the time I'm happy with this driver loaded at boot time. > > > I'm not sure. I'm running an SMP system with a Broadcom PCI card and > haven't run into this myself. Though that's with 6.0-RELEASE, not -current. > (I'm using the same NDIS code that's in -current though.) > > How often does it crash? 1 time of 3. >>>- Is it SMP or UP? >> >>SMP. > > > It's an SMP laptop? Really? Wow. Yeah! But it's just hyperthreaded. I'm running SMP only to help you find more bugs in kernel :) > > >>>When you provide this information, maybe you will get help. >>> >>>NOTE: Windows NDIS drivers assume that by the time you intialize them, >>>the entire OS is up and running, including scheduling and, if present, >>>multiple CPUs. But in FreeBSD, the kernel is running in 'cold start' >>>state when it probes/attaches devices, and not all of the scheduling >>>mechanisms are available yet (for example, you can not msleep() while >>>cold == 1). This means loading your driver via /boot/loader.conf is >>>something of a hit-or-miss proposition: sometimes they don't work right, >>>sometimes they do. To be really safe, you should load them _after_ the >>>system has come up all the way. >>> >>>Unfortunately, it's necessary to initialize the driver briefly in >>>ndis_attach() in order to find out the device's station address. (You >>>can only do it via MiniportQueryInformation(), and that only works after >>>MiniportInitialize() has been called.) >> >>When 'ntpdate' is called during boot process, everything is (or should >>be) initialized I believe. > > > Yes, but MiniportInitialize() has already been called once while cold == 1. > What I'm saying is you have to avoid doing that entirely. Try doing it > by loading bcmwl5_sys.ko after the system has gone multiuser. If the > problem persists, then I'm just full of crap (wouldn't be the first > time) and there's something else going wrong, but I think it bears > investigating. > OK, I'll awake this thread is the problem happens again. Thanks for looking into it! > -Bill -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 16:58:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C68DE16A41F; Fri, 11 Nov 2005 16:58:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2468C43D45; Fri, 11 Nov 2005 16:58:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jABGvxMa080516; Fri, 11 Nov 2005 11:57:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jABGw0Am088102; Fri, 11 Nov 2005 11:58:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EFF787302F; Fri, 11 Nov 2005 11:57:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051111165759.EFF787302F@freebsd-current.sentex.ca> Date: Fri, 11 Nov 2005 11:57:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 16:58:02 -0000 TB --- 2005-11-11 16:21:51 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-11 16:21:51 - starting HEAD tinderbox run for i386/i386 TB --- 2005-11-11 16:21:51 - cleaning the object tree TB --- 2005-11-11 16:22:29 - checking out the source tree TB --- 2005-11-11 16:22:29 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-11-11 16:22:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-11 16:28:45 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-11 16:28:45 - cd /src TB --- 2005-11-11 16:28: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 [...] rm -f .depend mkdep -f .depend -a /src/games/grdc/grdc.c echo grdc: /obj/src/tmp/usr/lib/libc.a /obj/src/tmp/usr/lib/libncurses.a >> .depend ===> games/morse (depend) rm -f .depend mkdep -f .depend -a -DSPEAKER=\"/dev/speaker\" /src/games/morse/morse.c /src/games/morse/morse.c:67:33: dev/speaker/speaker.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/games/morse. *** Error code 1 Stop in /src/games. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-11 16:57:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-11 16:57:59 - ERROR: failed to build world TB --- 2005-11-11 16:57:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 17:12:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF71216A41F for ; Fri, 11 Nov 2005 17:12:14 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADEE143D53 for ; Fri, 11 Nov 2005 17:12:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id D85ED5F52; Fri, 11 Nov 2005 12:12:09 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20500-01; Fri, 11 Nov 2005 12:12:08 -0500 (EST) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 1EC815C20; Fri, 11 Nov 2005 12:12:08 -0500 (EST) In-Reply-To: <1566.1131574723@critter.freebsd.dk> References: <1566.1131574723@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <916E69BA-AE58-4BB4-AB8A-01BDFBA5FF49@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 9 Nov 2005 19:39:10 -0500 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at codefab.com Cc: current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 17:12:15 -0000 On Nov 9, 2005, at 5:18 PM, Poul-Henning Kamp wrote: >> Apple has found that using inheritance is a big win for them: "In >> addition, code reusability decreases the memory footprint of drivers; >> drivers ported from Mac OS 9, for example, have been up to 75% >> smaller in Mac OS X." Of course, it's easier to say such things then >> to write the code, but Apple has achieved pretty good results from >> the IOKit. > > Apple also has significantly better control over the hardware > they have to write drivers for. Over their own hardware, agreed. However, there are a number of third-party hardware devices being used with Macs which Apple has no control over, things like GPS receivers using USB-to-serial converters, etc. Retaining backwards compatibility with older software, including older kernel modules (so long as they follow the rules), seems to be a very high priority for Apple, and they've done a fair-to-decent job of it. [ They've had some problems, too, such as VPN software breaking from 10.3 -> 10.4. ] > That said, there is a lot of stuff which could be improved in our > APIs. And I wouldn't mind getting a "C with classes" language with > a couple > of domain-specific extensions in the bargain. I'm not strongly advocating the use of C++ in the kernel, but Apple is using g++ to build their kernels, so I'd imagine that FreeBSD could utilize the same embedded C++ dialect in our kernels if people wanted to do so. The things that leapt out at me in comparing the FreeBSD APIs and IOKit were: 1) the notion of a system-wide driver registry, which could be obtained easily from the existing code in sys/bus.h & kern/subr_bus.c which keeps track of this: typedef TAILQ_HEAD(driver_list, driverlink) driver_list_t; [ devclass_get_devices() is close but not quite the same thing... ] 2) the "work loop" abstraction (long link, again): http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ IOKitFundamentals/HandlingEvents/chapter_8_section_2.html Programming using callbacks or continuations, having to serialize access to driver data structures, etc is one of the most difficult areas to deal with, and race conditions and so forth are a common source of evil, tricky, hard-to-reproduce bugs. There isn't a free lunch, the kernel has got to deal with such things, but having an abstraction like this would probably help make the lives of people writing drivers easier. [1] 3) the IOMemoryDescriptor and IOMemoryCursor classes, which provide an abstraction for managing virtual memory mappings and representing DMA or PIO activity (ie, building a scatter/gather list appropriate for a particular NIC or RAID controller's DMA engine): http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ IOKitFundamentals/DataMgmt/chapter_9_section_5.html -- -Chuck [1]: One _single_ abstraction, that is, rather than having lots of variants of similar code scattered hither and yon. From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 17:33:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE55816A41F; Fri, 11 Nov 2005 17:33:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B3F43D45; Fri, 11 Nov 2005 17:33:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jABHXoAL084069; Fri, 11 Nov 2005 12:33:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jABHXpeW081423; Fri, 11 Nov 2005 12:33:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 156CA7302F; Fri, 11 Nov 2005 12:33:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051111173351.156CA7302F@freebsd-current.sentex.ca> Date: Fri, 11 Nov 2005 12:33:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 17:33:52 -0000 TB --- 2005-11-11 16:58:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-11 16:58:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-11-11 16:58:00 - cleaning the object tree TB --- 2005-11-11 16:58:32 - checking out the source tree TB --- 2005-11-11 16:58:32 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-11-11 16:58:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-11 17:04:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-11 17:04:41 - cd /src TB --- 2005-11-11 17:04:41 - /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 [...] rm -f .depend mkdep -f .depend -a /src/games/grdc/grdc.c echo grdc: /obj/pc98/src/tmp/usr/lib/libc.a /obj/pc98/src/tmp/usr/lib/libncurses.a >> .depend ===> games/morse (depend) rm -f .depend mkdep -f .depend -a -DSPEAKER=\"/dev/speaker\" /src/games/morse/morse.c /src/games/morse/morse.c:67:33: dev/speaker/speaker.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/games/morse. *** Error code 1 Stop in /src/games. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-11 17:33:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-11 17:33:50 - ERROR: failed to build world TB --- 2005-11-11 17:33:50 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 20:59:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E986116A41F for ; Fri, 11 Nov 2005 20:59:46 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id B31C643D45 for ; Fri, 11 Nov 2005 20:59:46 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: by turing.cs.hmc.edu (Postfix, from userid 26983) id 1F323532DB; Fri, 11 Nov 2005 12:59:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by turing.cs.hmc.edu (Postfix) with ESMTP id 098075A8DE for ; Fri, 11 Nov 2005 12:59:45 -0800 (PST) Date: Fri, 11 Nov 2005 12:59:45 -0800 (PST) From: Nate Eldredge X-X-Sender: nate@turing To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Cross-compiling CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 20:59:47 -0000 Hi all, I have a test machine "tester" on which I am tracking CURRENT. However the machine is old and slow and takes a long time to compile the source. I want to do the compilation on another machine "builder" which is faster. However "builder" is a production machine running 5.4-RELEASE, with its own copy of the 5.4 source, and I want to leave that as it is. To further complicate matters "tester" is i386 while "builder" is amd64, so I must cross compile by setting TARGET_ARCH=i386. I have run into various snags while doing this and I was just wondering if there is a "right" way to do this, or if anyone has any useful advice. I have read the section of the handbook on "Tracking for Multiple Machines" but it assumes the test and build machines are homogeneous, which is not my situation. The first problem is that "tester" has various compilation options set in its /etc/make.conf which disagree with those of "builder". I worked around this by setting the undocumented __MAKE_CONF to point to tester's make.conf when compiling on builder. Is this right? After this "builder" is able to compile the whole tree, but there are problems trying to install it on "tester" due to path names. Currently on "builder" the source resides in /foo/src and is compiled into /bar/obj (by setting MAKEOBJDIRPREFIX to /bar/obj). These are NFS mounted on tester:/usr/src and tester:/usr/obj. But when I run "make install" in tester:/usr/src, it looks for the binaries in /usr/obj/usr/src/* whereas they really appear in /usr/obj/i386/foo/src/*. I could correct this with symlinks, or by creating and mounting on tester:/foo/src and tester:/bar/obj so that the paths agree, but this is sort of annoying. Any better ways? Lastly, I would rather have src/ and obj/ mounted read-only on tester. (The filesystem on builder where they are located already has some other things NFS-exported readonly, and as you probably know FreeBSD won't allow you to export directories from the same fs with different options.) Is this going to work, or do these have to be writable for install to succeed? Thanks in advance for any suggestions. -- Nate Eldredge nge@cs.hmc.edu From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 21:00:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC55716A421 for ; Fri, 11 Nov 2005 21:00:40 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB3C43D46 for ; Fri, 11 Nov 2005 21:00:39 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp5-g19.free.fr (Postfix) with ESMTP id 5EE6F9776 for ; Fri, 11 Nov 2005 22:00:37 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jABL0Udd001672 for ; Fri, 11 Nov 2005 22:00:36 +0100 (CET) From: Thierry Herbelot To: current@freebsd.org Date: Fri, 11 Nov 2005 22:00:22 +0100 User-Agent: KMail/1.8.3 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511112200.23138.thierry@herbelot.com> Cc: Subject: Panic while idle ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 21:00:41 -0000 Hello, with a recent -current cvs-ing the sources from an NFS repository, I just had the following panic : (on an SMP box) cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc07fad79 stack pointer = 0x28:0xc6cd3cf8 frame pointer = 0x28:0xc6cd3cf8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (idle: cpu0) [thread pid 12 tid 100004 ] Stopped at cpu_idle_default+0x5: leave db> trace Tracing pid 12 tid 100004 td 0xc16de900 cpu_idle_default(c6cd3d0c,c0632b29,c0632acc,c6cd3d24,c063290c) at cpu_idle_default+0x5 cpu_idle(c0632acc,c6cd3d24,c063290c,0,c6cd3d38) at cpu_idle+0x28 idle_proc(0,c6cd3d38,0,c0632acc,0) at idle_proc+0x5d fork_exit(c0632acc,0,c6cd3d38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc6cd3d6c, ebp = 0 --- db> From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 21:13:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2BFD16A420 for ; Fri, 11 Nov 2005 21:13:40 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B874D43D6D for ; Fri, 11 Nov 2005 21:13:36 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jABLDTfd014896; Fri, 11 Nov 2005 23:13:29 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 93324-01-4; Fri, 11 Nov 2005 23:13:28 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jABLD7Cb014862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 23:13:07 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jABLDE2V002453; Fri, 11 Nov 2005 23:13:14 +0200 (EET) (envelope-from ru) Date: Fri, 11 Nov 2005 23:13:13 +0200 From: Ruslan Ermilov To: Nate Eldredge Message-ID: <20051111211313.GL87446@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RVlUGXxwBj5SDcM9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@freebsd.org Subject: Re: Cross-compiling CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 21:13:41 -0000 --RVlUGXxwBj5SDcM9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2005 at 12:59:45PM -0800, Nate Eldredge wrote: > Hi all, >=20 > I have a test machine "tester" on which I am tracking CURRENT. However= =20 > the machine is old and slow and takes a long time to compile the source.= =20 > I want to do the compilation on another machine "builder" which is faster= =2E=20 > However "builder" is a production machine running 5.4-RELEASE, with its= =20 > own copy of the 5.4 source, and I want to leave that as it is. To furthe= r=20 > complicate matters "tester" is i386 while "builder" is amd64, so I must= =20 > cross compile by setting TARGET_ARCH=3Di386. >=20 > I have run into various snags while doing this and I was just wondering i= f=20 > there is a "right" way to do this, or if anyone has any useful advice. I= =20 > have read the section of the handbook on "Tracking for Multiple Machines"= =20 > but it assumes the test and build machines are homogeneous, which is not= =20 > my situation. >=20 > The first problem is that "tester" has various compilation options set in= =20 > its /etc/make.conf which disagree with those of "builder". I worked=20 > around this by setting the undocumented __MAKE_CONF to point to tester's= =20 > make.conf when compiling on builder. Is this right? >=20 > After this "builder" is able to compile the whole tree, but there are=20 > problems trying to install it on "tester" due to path names. Currently o= n=20 > "builder" the source resides in /foo/src and is compiled into /bar/obj (b= y=20 > setting MAKEOBJDIRPREFIX to /bar/obj). These are NFS mounted on=20 > tester:/usr/src and tester:/usr/obj. But when I run "make install" in=20 > tester:/usr/src, it looks for the binaries in /usr/obj/usr/src/* whereas= =20 > they really appear in /usr/obj/i386/foo/src/*. I could correct this with= =20 > symlinks, or by creating and mounting on tester:/foo/src and=20 > tester:/bar/obj so that the paths agree, but this is sort of annoying.=20 > Any better ways? >=20 > Lastly, I would rather have src/ and obj/ mounted read-only on tester.=20 > (The filesystem on builder where they are located already has some other= =20 > things NFS-exported readonly, and as you probably know FreeBSD won't allo= w=20 > you to export directories from the same fs with different options.) Is= =20 > this going to work, or do these have to be writable for install to=20 > succeed? >=20 The only way it can work is to do everything on builder, including installing bits on tester. I do this by NFS-mounting /, /var and /usr partitions from tester on builder's /mnt, and doing install (kernel+world) with the same options as build*, and specifying DESTDIR=3D/mnt. Make sure to "chflags -R 0" on tester before doing this for the first time. I also use top-level "distrib-dirs" and "distribution" targets with TARGET_ARCH to populate /mnt/var/tmp/`date +%Y%m%d` directory, to update /etc etc. I have no idea if mergemaster(8) works with TARGET_ARCH and/or DESTDIR. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --RVlUGXxwBj5SDcM9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDdQlpqRfpzJluFF4RAoIRAJ0SKeN+o5wb8tQld8t0jTpvqNGIkACdHA+r Q6GJFVgGl+xpqFJ0tljnoFg= =RQqm -----END PGP SIGNATURE----- --RVlUGXxwBj5SDcM9-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 21:24:37 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D8C616A44F; Fri, 11 Nov 2005 21:24:37 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6EF43D45; Fri, 11 Nov 2005 21:24:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1777351 for multiple; Fri, 11 Nov 2005 16:22:33 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jABLOXmS081579; Fri, 11 Nov 2005 16:24:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, thierry@herbelot.com Date: Fri, 11 Nov 2005 16:19:59 -0500 User-Agent: KMail/1.8.2 References: <200511112200.23138.thierry@herbelot.com> In-Reply-To: <200511112200.23138.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511111620.00731.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: current@freebsd.org Subject: Re: Panic while idle ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 21:24:37 -0000 On Friday 11 November 2005 04:00 pm, Thierry Herbelot wrote: > Hello, > > with a recent -current cvs-ing the sources from an NFS repository, I just > had the following panic : (on an SMP box) > > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc07fad79 > stack pointer = 0x28:0xc6cd3cf8 > frame pointer = 0x28:0xc6cd3cf8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 12 (idle: cpu0) > [thread pid 12 tid 100004 ] > Stopped at cpu_idle_default+0x5: leave > db> trace > Tracing pid 12 tid 100004 td 0xc16de900 > cpu_idle_default(c6cd3d0c,c0632b29,c0632acc,c6cd3d24,c063290c) at > cpu_idle_default+0x5 > cpu_idle(c0632acc,c6cd3d24,c063290c,0,c6cd3d38) at cpu_idle+0x28 > idle_proc(0,c6cd3d38,0,c0632acc,0) at idle_proc+0x5d > fork_exit(c0632acc,0,c6cd3d38) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc6cd3d6c, ebp = 0 --- > db> Was there an additional line specifying which type of trap? -- 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 Nov 11 21:24:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D8C616A44F; Fri, 11 Nov 2005 21:24:37 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6EF43D45; Fri, 11 Nov 2005 21:24:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1777351 for multiple; Fri, 11 Nov 2005 16:22:33 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jABLOXmS081579; Fri, 11 Nov 2005 16:24:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, thierry@herbelot.com Date: Fri, 11 Nov 2005 16:19:59 -0500 User-Agent: KMail/1.8.2 References: <200511112200.23138.thierry@herbelot.com> In-Reply-To: <200511112200.23138.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511111620.00731.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: current@freebsd.org Subject: Re: Panic while idle ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 21:24:37 -0000 On Friday 11 November 2005 04:00 pm, Thierry Herbelot wrote: > Hello, > > with a recent -current cvs-ing the sources from an NFS repository, I just > had the following panic : (on an SMP box) > > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc07fad79 > stack pointer = 0x28:0xc6cd3cf8 > frame pointer = 0x28:0xc6cd3cf8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 12 (idle: cpu0) > [thread pid 12 tid 100004 ] > Stopped at cpu_idle_default+0x5: leave > db> trace > Tracing pid 12 tid 100004 td 0xc16de900 > cpu_idle_default(c6cd3d0c,c0632b29,c0632acc,c6cd3d24,c063290c) at > cpu_idle_default+0x5 > cpu_idle(c0632acc,c6cd3d24,c063290c,0,c6cd3d38) at cpu_idle+0x28 > idle_proc(0,c6cd3d38,0,c0632acc,0) at idle_proc+0x5d > fork_exit(c0632acc,0,c6cd3d38) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc6cd3d6c, ebp = 0 --- > db> Was there an additional line specifying which type of trap? -- 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 Nov 11 20:40:17 2005 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4EBC16A41F for ; Fri, 11 Nov 2005 20:40:17 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DD743D49 for ; Fri, 11 Nov 2005 20:40:16 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4) with ESMTP id jABKeAkt015748 for ; Fri, 11 Nov 2005 21:40:10 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jABKe917015745 for ; Fri, 11 Nov 2005 21:40:10 +0100 Date: Fri, 11 Nov 2005 21:40:09 +0100 (CET) From: Goran Gajic To: freebsd-current@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Fri, 11 Nov 2005 21:25:15 +0000 Cc: Subject: 6.0-RELESE + xfs-snap20051015 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Nov 2005 20:40:17 -0000 Hi, I have installed 6.0-RELEASE and xfs-snap20051015 from http://people.freebsd.org/~kan/xfs/. Unfortunately I'm not able to mount any of my xfs partitons. I have used GENERIC config to build kernel, first applying /usr/src/xfs-src.diff. I have tried both with options XFS appended at the end of config file and with XFS as module. If it is built as module xfs.ko can't be loaded: # kldload xfs.ko link_elf: symbol db_error undefined kldload: can't load xfs.ko: No such file or directory # ls -al /boot/kernel/xfs.ko -r-xr-xr-x 1 root wheel 458464 Nov 11 21:25 /boot/kernel/xfs.ko # kldload /boot/kernel/xfs.ko link_elf: symbol db_error undefined kldload: can't load /boot/kernel/xfs.ko: No such file or directory # With or without options XFS mount_xfs gives same result: # mount_xfs /dev/ad1s1 /mnt mount_xfs: /dev/ad1s1: Invalid argument # It gives same result for any partiton containing xfs. Here is uname -a FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #3: Fri Nov 11 21:23:43 CET 2005 root@:/usr/src/sys/i386/compile/TEST i386 ad0: 78167MB at ata0-master UDMA100 ad1: 238475MB at ata0-slave UDMA100 Regards, Goran Gajic From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 21:38:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D54D16A41F; Fri, 11 Nov 2005 21:38:23 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1823C43D45; Fri, 11 Nov 2005 21:38:23 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp6-g19.free.fr (Postfix) with ESMTP id 0779896C4; Fri, 11 Nov 2005 22:38:21 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id jABLcJrC009182; Fri, 11 Nov 2005 22:38:20 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 11 Nov 2005 22:38:11 +0100 User-Agent: KMail/1.8.3 References: <200511112200.23138.thierry@herbelot.com> <200511111620.00731.jhb@freebsd.org> In-Reply-To: <200511111620.00731.jhb@freebsd.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200511112238.12355.thierry@herbelot.com> Cc: Subject: Re: Panic while idle ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 21:38:23 -0000 Le Friday 11 November 2005 22:19, John Baldwin a écrit : > On Friday 11 November 2005 04:00 pm, Thierry Herbelot wrote: > > Hello, > > > > with a recent -current cvs-ing the sources from an NFS repository, I just > > had the following panic : (on an SMP box) > > > > cpuid = 0; apic id = 00 > > instruction pointer = 0x20:0xc07fad79 > > stack pointer = 0x28:0xc6cd3cf8 > > frame pointer = 0x28:0xc6cd3cf8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, IOPL = 0 > > current process = 12 (idle: cpu0) > > [thread pid 12 tid 100004 ] > > Stopped at cpu_idle_default+0x5: leave > > db> trace > > Tracing pid 12 tid 100004 td 0xc16de900 > > cpu_idle_default(c6cd3d0c,c0632b29,c0632acc,c6cd3d24,c063290c) at > > cpu_idle_default+0x5 > > cpu_idle(c0632acc,c6cd3d24,c063290c,0,c6cd3d38) at cpu_idle+0x28 > > idle_proc(0,c6cd3d38,0,c0632acc,0) at idle_proc+0x5d > > fork_exit(c0632acc,0,c6cd3d38) at fork_exit+0xa4 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xc6cd3d6c, ebp = 0 --- > > db> > > Was there an additional line specifying which type of trap? unfortunately, no (the machine is currently -slowly- fsck-ing and rebuilding a gmirror) I also have : an extract of the ps listing 13 c16dd678 0 0 0 0000204 [IWAIT] swi1: net 12 c16dd8a0 0 0 0 000020c [CPU 0] idle: cpu0 11 c16ddac8 0 0 0 000020c [CPU 1] idle: cpu1 1 c16ddcf0 0 0 1 0004200 [SLPQ wait 0xc16ddcf0][SLP] init TfH From owner-freebsd-current@FreeBSD.ORG Fri Nov 11 22:09:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4048516A41F for ; Fri, 11 Nov 2005 22:09:35 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: from smtp101.biz.mail.mud.yahoo.com (smtp101.biz.mail.mud.yahoo.com [68.142.200.236]) by mx1.FreeBSD.org (Postfix) with SMTP id CB54D43D45 for ; Fri, 11 Nov 2005 22:09:34 +0000 (GMT) (envelope-from ke.han@redstarling.com) Received: (qmail 93309 invoked from network); 11 Nov 2005 22:09:34 -0000 Received: from unknown (HELO ?192.168.1.2?) (jhancock@patternware.com@218.79.199.193 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 11 Nov 2005 22:09:33 -0000 Message-ID: <43751695.7080702@redstarling.com> Date: Sat, 12 Nov 2005 06:09:25 +0800 From: "ke.han" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Devon H. O'Dell" References: <2B3B2AA816369A4E87D7BE63EC9D2F26F01193@SDCEXCHANGE01.ad.amcc.com> <43715294.3080604@redstarling.com> <9ab217670511081836t7e21b0e3k@mail.gmail.com> <437170B9.3020709@redstarling.com> <9ab217670511082014w467ab180i@mail.gmail.com> <43719123.5080306@redstarling.com> <9ab217670511082252s628db890j@mail.gmail.com> In-Reply-To: <9ab217670511082252s628db890j@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3ware 9550sx driver for freeBSD 6 amd64 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2005 22:09:35 -0000 Devon H. O'Dell wrote: > No problem. > > The kernel is for AMD64. > > What you may be able to do is drop to the bootloader prompt and unload > kernel. After that, you should be able to indeed load the kernel from > the other CD, plop the original back in there and boot. > --Devon > Devon, I was able to unload the install iso kernel and load the one you posted. Unfortunately, still no good. The driver seems to be there and trying to communicate with the 9550sx, but I get errors at the end of the boot process. Here are steps I took: 1 - boot w/ freeBSD 6.0-RELEASE amd64 install cd 1 2 - step into phase 3 boot loader prompt 3 - unload kernel 4 - swap cds 5 - load cd0:KERNEL_9;1 (for some reason this is how freeBSD sees the file even though I burned the iso with a file named kernel_9550sx) 6 - swap the cds back 7 - boot ...all goes well until it looks like everything is done booting and then there is about a minute wait and I start getting the following messages: twa0: ERROR: (0x05:0x210b): Request timed out!: request = 0xffffffff80c52000 twa0: INFO: (0x16:0x1108): Resetting controller...: twa0: INFO: (0x04:0x0001):Controller reset occurred: resets=1 twa0: INFO: (0x16:-x1107): Controller reset done! The message cycle continues every few minutes with an increment of the resets counter and the request info. I tried this both before and after updating the firmware of the 9550sx. The firmware was originally FE9X 3.01.01.028. Upgraded to FE9X 3.02.00.04. I am running this on a new server I put together especially for freeBSD 6. The motherboard is Tyan i7520. So far, freeBSD has never once found a hard drive controller in the 3rd phase boot of this machine. It can't find a simple EIDE or SATA when directly connected to the corresponding motherboard controller (and the 9550sx card removed). And this 3ware card...well, you see the errors. Linux (Centos 4.2) and Windows Server 2003 install just fine under all the configs which freeBSD 6 amd64 and i386 fails. freeBSD 5.4 also fails. Any more ideas? thanks, ke han From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 00:19:56 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2C5816A41F; Sat, 12 Nov 2005 00:19:56 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2858B43D46; Sat, 12 Nov 2005 00:19:55 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.99.202] (host165-171.pool872.interbusiness.it [87.2.171.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id DCD4D5747; Sat, 12 Nov 2005 01:24:33 +0100 (CET) Message-ID: <43753528.7030802@freesbie.org> Date: Sat, 12 Nov 2005 01:19:52 +0100 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Pressey , current@freebsd.org, geom@freebsd.org References: <20051027200448.1ba236fe.cpressey@catseye.mine.nu> In-Reply-To: <20051027200448.1ba236fe.cpressey@catseye.mine.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: fdisk(8) no longer capable of altering geometry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 00:19:56 -0000 My little follow-up to this issue. This bug is quite critical on products using bsdinstaller such as FreeSBIE or pfSense. I heard rumours that PC-BSD also encounter this problem and had to workaround it by sysinstall. Can somebody please take a look at it? Thanks, Dario Chris Pressey wrote: > [this is a follow-up to / correction of my post to geom@ a few days ago, > to which there was no reply] > > Hello, > > It appears that fdisk(8) is no longer capable of altering the geometry > of a disk. (By which I mean, the kernel's idea of the BIOS'es idea of > the geometry, of course.) I'd find it reassuring to know whether or not > anyone else is seeing the same behaviour, before I go the official route > and file a PR. > > Initially I thought that this failure case was only for uninitialized > disks, but I have tried further tests and I can't get fdisk(8) to change > the geometry in any of the cases. These cases are: > > a. uninitialized, totally blank disk (dd if=/dev/zero of=/dev/ad1 ...) > b. initialized disk with FreeBSD (or any other OS) installed on it > c. same as b, but with its root partition mounted on /mnt > d. the disk containing the currently booted FreeBSD system > (mounted on /, of course) > > In each of these cases, I tried a sequence like the following: > > fdisk -BI ad1 > fdisk -u ad1 > say yes, and plug in different but compatible values for cylinders, > heads, and sectors/track> > > fdisk ad1 > > > The behaviour I see is, in summary: > > a & b: fdisk issues the warning "fdisk: Geom not found" which presumably > refers to the fact that there is no GEOM MBR provider for that > disk. It then falls back to the legacy behaviour of raw-writing > the partition table into sector zero of the disk. This does not, > however, trigger an update of the kernel's idea of the geometry. > > c & d: no "Geom not found" warning, but no change in geometry either. > > I don't see this behaviour on DragonFly; cases a and b work as you would > logically expect (as they worked in 4.x, AFAIR, but I have not yet > tested this) where the geometry does get changed, and subsequent runs of > fdisk report the changed geometry. > > In cases c & d, the behaviour is the same as FreeBSD - nothing changes. > This is not too surprising, since the disk _is_ in use - but an error > message would probably make more sense. > > This bug is one of the few remaining things standing in the way of > porting the BSD Installer to FreeBSD. Without some way of altering the > the geometry, it can't install onto a system whose BIOS misreports the > disk geometry. > > My analysis of the problem can be found in my previous post to geom@, > but to sum it up: I think fdisk needs to inform GEOM somehow that the > geometry should be changed. It might need to trigger the creation of a > GEOM MBR provider for the disk before it does so; but I'm not certain of > any of this, since my knowledge of GEOM is slim at best. > > Hopefully someone more familiar with GEOM and such under -CURRENT is > listening and can shed more light on this problem and/or provide a > workaround and/or explain how I'm wrong and show me the right way to do > what I'm trying to do (change geometry) in -CURRENT. > > Thanks for your time, > -Chris > _______________________________________________ > 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" > -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 00:23:08 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB79F16A41F for ; Sat, 12 Nov 2005 00:23:08 +0000 (GMT) (envelope-from pete@altadena.net) Received: from puffin.altadena.net (puffin.altadena.net [207.151.161.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D48443D45 for ; Sat, 12 Nov 2005 00:23:08 +0000 (GMT) (envelope-from pete@altadena.net) Received: from nat-gw.home.altadena.net ([66.127.158.99] helo=[192.168.169.28]) by puffin.altadena.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1EajAh-000EXl-G4 for current@freebsd.org; Fri, 11 Nov 2005 16:23:07 -0800 Message-ID: <437535E4.2010400@altadena.net> Date: Fri, 11 Nov 2005 16:23:00 -0800 From: Pete Carah Organization: Altadena Internet Communications User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Crash using tun device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 00:23:09 -0000 I now (cvsup as of a day ago, and also from a week ago) see a spontaneous reboot when using the tun device from userland ppp. This occurs with either umodem or an ssh tunnel on the serial side, and crashes immediately after the IP addresses are set. I don't know if it is in route setting or not; the ssh tunnel script doesn't set the default route via the tunnel (shoot self in foot, anyone?). I didn't see this a month or two ago afaik, though it has been a while since I had to use ppp on either laptop. This also occurs whether if_tun is compiled into the kernel or kldloaded, and on a i386 and amd64 at exactly the same time. I'm presuming the problem isn't in /dev/tty or ucom since the ssh tunnel and my terminal interfaces both use tty, and I've done much raw-mode stuff with ucom lately. That leaves if_tun and its routing/arp interface. (though ppp doesn't use arp...), and various kernel interfaces to/from it (note that broadcast networks (ethernet and wlan) work fine. I haven't tried vlan lately in -current, though. The ppp.log shows the ip address setting line and nothing further as far as I can see (though the crash is VERY quick after that line shows up.) -- Pete From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 01:04:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 549A616A41F; Sat, 12 Nov 2005 01:04:36 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6204E43D45; Sat, 12 Nov 2005 01:04:35 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 35922273 for multiple; Fri, 11 Nov 2005 18:13:58 -0700 Date: Fri, 11 Nov 2005 19:09:32 -0600 From: Vulpes Velox To: wpaul@FreeBSD.ORG (Bill Paul) Message-ID: <20051111190932.25ad86af@vixen42.vulpes> In-Reply-To: <20051111054207.17ED516A421@hub.freebsd.org> References: <20051110212148.7a335fd9@vixen42.vulpes> <20051111054207.17ED516A421@hub.freebsd.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-NotAscii: charset=us-ascii X-IP-stats: Incoming Last 0, First 40, in=66, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 01:04:36 -0000 On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) wpaul@FreeBSD.ORG (Bill Paul) wrote: > > Ran into a few problems with ndisgen today. > > > > I have to edit every instance of the following out to get it to > > convert. > > Magic Packet = "Magic Packet" > > Pattern Match = "Pattern Match" > > Mag Pack Patt Match = "Magic Packet & Pattern Match" > > Link Change = "Link Change" > > > > > > Upon loading the driver I get... > > no match for ExUnregisterCallback > > no match for ZwPowerInformation > > no match for ExRegisterCallback > > no match for ExCreateCallback > > no match for ZwUnmapViewOfSection > > no match for ZwMapViewOfSection > > no match for ZwOpenSection > > no match for wcslen > > > > Any chance of getting this working or any suggestions? > > > > Ok, had I read the subject line of your mail fully I'd have known > what driver it was. I'm a dolt and I've clearly had too long of a > day. > > Here are the problems: > > - I don't know exactly what driver image you have. Unless you > provide the URL for where you got it to put a copy somewhere, > I can't really analyze it. http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 IIRC the installer dumps it Program Files/Marvell It is where I grabbed the .sys and . > - The .inf parser is not perfect. It's actually much stricter > about syntax than Windows is. Stuff that works ok for Windows > may be flagged as a syntax error by ndiscvt. If someone wants > to help fix this, they're welcome to. (No kernel hacking > required.) Cool, any suggested reads? > - I have no earthy idea why Marvell is referencing these functions > in their driver. They're totally outside the NDIS spec. I'd be > rather surprised that such a driver was able to get WHQL > certification. (Assuming it did.) > > - This is Marvell. Given the rotten treatment I've had from them > in the past, I'm not inclined to do them any favors now, so I'm > not exactly inclined to fix this anytime soon. Fun, what happened, if I may ask? From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 02:29:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E866316A41F for ; Sat, 12 Nov 2005 02:29:36 +0000 (GMT) (envelope-from bazerka@beardz.net) Received: from www.beardz.net (host86-139-2-39.range86-139.btcentralplus.com [86.139.2.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C57943D49 for ; Sat, 12 Nov 2005 02:29:35 +0000 (GMT) (envelope-from bazerka@beardz.net) Received: from [127.0.0.1] ([127.0.0.1]) by www.beardz.net with Microsoft SMTPSVC(6.0.2600.2180); Sat, 12 Nov 2005 02:29:51 +0000 Message-ID: <4375539F.6050405@beardz.net> Date: Sat, 12 Nov 2005 02:29:51 +0000 From: Jase Thew User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vulpes Velox References: <20051110212148.7a335fd9@vixen42.vulpes> <20051111054207.17ED516A421@hub.freebsd.org> <20051111190932.25ad86af@vixen42.vulpes> In-Reply-To: <20051111190932.25ad86af@vixen42.vulpes> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2005 02:29:51.0890 (UTC) FILETIME=[F5D74720:01C5E730] Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 02:29:37 -0000 Vulpes Velox wrote: > On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) > > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 > > IIRC the installer dumps it Program Files/Marvell It is where I > grabbed the .sys and . > Hi, I'd suggest trying these drivers instead : http://marvell.com/drivers/driverDisplay.do?dId=116&pId=3 These are the Yukon GigE NDIS5.1 miniport drivers for Windows XP, and I have a feeling you'll have better luck with these. Hope this helps. Regards, Jase. From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 00:35:31 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6119216A41F for ; Sat, 12 Nov 2005 00:35:31 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23E0343D46 for ; Sat, 12 Nov 2005 00:35:31 +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 D4B23F24BB for ; Fri, 11 Nov 2005 16:35:30 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00818-07 for ; Fri, 11 Nov 2005 16:35:30 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 5BB12F2453 for ; Fri, 11 Nov 2005 16:35:30 -0800 (PST) From: Sean McNeil To: current@freebsd.org Content-Type: text/plain Date: Fri, 11 Nov 2005 16:35:30 -0800 Message-Id: <1131755730.6959.7.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Sat, 12 Nov 2005 03:05:13 +0000 Cc: Subject: verrevpath failure from within my own box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 00:35:31 -0000 I was wondering... is there is any valid time when FreeBSD would generate improper revpaths? My setup is on a 6-STABLE system with the patch from suz to ip_fw2.c that fixes a revpath problem. It is setup as dc0 - external nic with natd and ipfw2 sk0 - internal nic The rule is 00300 28 2177 deny ip from any to any not verrevpath in via dc0 as you can see, there are some packets that were denied. I can reproduce this with nautilus by simply browsing network:///. I've even unplugged the cables from the nics to make sure it wasn't some bad response to a network query. It is not. They are being generated within my box. Sean From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 03:47:54 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B69C516A42F for ; Sat, 12 Nov 2005 03:47:54 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1120E43D45 for ; Sat, 12 Nov 2005 03:47:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jAC3loMs024956 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 12 Nov 2005 14:47:51 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jAC3loHh086722; Sat, 12 Nov 2005 14:47:50 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jAC3lobT086721; Sat, 12 Nov 2005 14:47:50 +1100 (EST) (envelope-from pjeremy) Date: Sat, 12 Nov 2005 14:47:50 +1100 From: Peter Jeremy To: Sean McNeil Message-ID: <20051112034750.GC39882@cirb503493.alcatel.com.au> References: <1131755730.6959.7.camel@triton.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131755730.6959.7.camel@triton.mcneil.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: current@freebsd.org Subject: Re: verrevpath failure from within my own box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 03:47:54 -0000 On Fri, 2005-Nov-11 16:35:30 -0800, Sean McNeil wrote: >00300 28 2177 deny ip from any to any not verrevpath in via dc0 > >as you can see, there are some packets that were denied. I can >reproduce this with nautilus by simply browsing network:///. How about you add a 'log' to that rule and see exactly what is matching. That may provide a clue to you, or someone on this list, as to what is not behaving as expected. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 04:11:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A54916A41F for ; Sat, 12 Nov 2005 04:11:00 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA64C43D45 for ; Sat, 12 Nov 2005 04:10:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 81859F2521; Fri, 11 Nov 2005 20:10:59 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (triton.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49131-04; Fri, 11 Nov 2005 20:10:59 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 1E61CF2453; Fri, 11 Nov 2005 20:10:59 -0800 (PST) From: Sean McNeil To: Peter Jeremy In-Reply-To: <20051112034750.GC39882@cirb503493.alcatel.com.au> References: <1131755730.6959.7.camel@triton.mcneil.com> <20051112034750.GC39882@cirb503493.alcatel.com.au> Content-Type: text/plain Date: Fri, 11 Nov 2005 20:10:58 -0800 Message-Id: <1131768658.78554.2.camel@triton.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com X-Mailman-Approved-At: Sat, 12 Nov 2005 04:18:08 +0000 Cc: current@freebsd.org Subject: Re: verrevpath failure from within my own box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 04:11:00 -0000 On Sat, 2005-11-12 at 14:47 +1100, Peter Jeremy wrote: > On Fri, 2005-Nov-11 16:35:30 -0800, Sean McNeil wrote: > >00300 28 2177 deny ip from any to any not verrevpath in via dc0 > > > >as you can see, there are some packets that were denied. I can > >reproduce this with nautilus by simply browsing network:///. > > How about you add a 'log' to that rule and see exactly what is matching. > That may provide a clue to you, or someone on this list, as to what is > not behaving as expected. OK, I did that. I see Nov 11 20:06:37 triton kernel: ipfw: 300 Deny UDP 24.199.45.54:63716 24.199.45.55:137 in via dc0 where 24.199.45.54 is the ip address of dc0. Nothing I didn't expect. Sean From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 04:36:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 9077C16A420; Sat, 12 Nov 2005 04:36:01 +0000 (GMT) In-Reply-To: <20051111190932.25ad86af@vixen42.vulpes> from Vulpes Velox at "Nov 11, 2005 07:09:32 pm" To: v.velox@vvelox.net (Vulpes Velox) Date: Sat, 12 Nov 2005 04:36:01 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051112043601.9077C16A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 04:36:01 -0000 > On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) > wpaul@FreeBSD.ORG (Bill Paul) wrote: > > > > Ran into a few problems with ndisgen today. > > > > > > I have to edit every instance of the following out to get it to > > > convert. > > > Magic Packet = "Magic Packet" > > > Pattern Match = "Pattern Match" > > > Mag Pack Patt Match = "Magic Packet & Pattern Match" > > > Link Change = "Link Change" > > > > > > > > > Upon loading the driver I get... > > > no match for ExUnregisterCallback > > > no match for ZwPowerInformation > > > no match for ExRegisterCallback > > > no match for ExCreateCallback > > > no match for ZwUnmapViewOfSection > > > no match for ZwMapViewOfSection > > > no match for ZwOpenSection > > > no match for wcslen > > > > > > Any chance of getting this working or any suggestions? > > > > > > > Ok, had I read the subject line of your mail fully I'd have known > > what driver it was. I'm a dolt and I've clearly had too long of a > > day. > > > > Here are the problems: > > > > - I don't know exactly what driver image you have. Unless you > > provide the URL for where you got it to put a copy somewhere, > > I can't really analyze it. > > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 > > IIRC the installer dumps it Program Files/Marvell It is where I > grabbed the .sys and . I can probably unscramble it with Wine. I've had pretty good luck with it with other driver distribution. > > - The .inf parser is not perfect. It's actually much stricter > > about syntax than Windows is. Stuff that works ok for Windows > > may be flagged as a syntax error by ndiscvt. If someone wants > > to help fix this, they're welcome to. (No kernel hacking > > required.) > > Cool, any suggested reads? The Microsoft MSDN site is the canonical source for documentation, such as it is. I would start with something like: http://www.microsoft.com/whdc/archive/W2inf.mspx The .INF syntax is very subtle: it's evolved a lot over time and you can use it to produce many strange effects. For example, it's possible to create a .INF file that can figure out if you're on a Win98, Win2K or WinXP system and install a different driver for each one. Another major source of complication is registry key specifications. NDIS drivers tend to specify only a few keys that need to be created at install time, but it's possible to create large numbers of them for various purposes. I've seen a Conexant modem driver that uses its .INF file to store a bunch of special keys containing some kind of binary patch tables that are used by the driver at runtime. There's also different patch tables for different chipsets. > > - I have no earthy idea why Marvell is referencing these functions > > in their driver. They're totally outside the NDIS spec. I'd be > > rather surprised that such a driver was able to get WHQL > > certification. (Assuming it did.) Some investigation shows that they're probably using ExRegisterCallback() and its ilk to obtain notification about power state events. And I think they're using ZwMapViewOfSection() to basically do 'vtophys(),' i.e. map a physical address to a virtual one, probably so they can access some card resident RAM that's mapped into the host. (Actually, ZwMapViewOfSection() lets you read from the \Devices\PhysicalMemory device, so really it's the equivalent of grovelling around in /dev/mem.) I'm unsure why they're doing this. I was under the impression you were supposed to have a MiniportPnpEvent() method to handle power event notifications. As for the physical/virtual address translation thing, they could have used NdisMMapIoSpace() or maybe even MmMapIoSpace() instead. Who knows. > > - This is Marvell. Given the rotten treatment I've had from them > > in the past, I'm not inclined to do them any favors now, so I'm > > not exactly inclined to fix this anytime soon. > > Fun, what happened, if I may ask? Back when the patches to support the Yukon with sk(4) were first merged in, and people were having problems with multicast, I asked one of my SysKonnect contacts (who had now been assimilated by Marvell) for the Yukon manuals so I could fix it. They told me that I would need to sign both an NDA, and a software license agreement. I thought this was strange since I wasn't licensing them my software and they weren't licensing me theirs, but I told them I wanted official recognition of the fact that this was an open source project and that's what they came up with. I said "ok, send me both documents so I can read them." They sent me the NDA, but not the software license agreement. I wanted both before I would sign anything, and kept prodding my contact to send the license agreement, but he kept begging off and promising to talk with the right people. Finally after about a month of this, I finally got an e-mail from someone else telling me that they had decided they were going to produce their own binary driver (actually, they had been working on it all along) and because of that they saw no need to give me the manuals now. But they did offer me some free sample cards. I told them I was terminating any further involvement with SysKonnect and Marvell and they could keep their cards. I still have the e-mails from them archived somewhere. Some time later (I'm not sure how long, maybe a month or two), I was contacted via e-mail by a SysKonnect/Marvell engineer in Germany who wanted to know if we could make the sk(4) driver optional so that their customers could use their binary only driver without having to recompile the kernel. I told him flatly that I wasn't on speaking terms with his company anymore and that he was out of luck. I was startled to receive a phone call from him shortly after. He was rather taken aback and curious to know why I had become so unhappy with his company, so I explain to him how his Marvell overlords had stonewalled me earlier. He was very surprised and disappointed. He seemed like a nice fellow and I told him while I had nothing against him personally, but I was not about to make Marvell's life easier when they had made mine so miserable. During our conversation, I found out that he had been tasked with developing the Yukon driver for FreeBSD. Then it was my turn to be taken aback, when he admitted to me that he hadn't actually read the Yukon manual: instead, he had been provided with an API library for communicating with the card and was essentially producing a wrapper for that library to interface it with FreeBSD. Now, this technique is not new: Broadcom and other vendors have been using it for a long time. But even so, I would like to think that library or no, the engineers writing the drivers are actually familiar with the hardware. So you can understand why I'm not in any hurry to do anything nice for them. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 08:08:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4CDD16A41F; Sat, 12 Nov 2005 08:08:41 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5172D43D46; Sat, 12 Nov 2005 08:08:41 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1EaqRD-0001F7-PP; Sat, 12 Nov 2005 10:08:39 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: wpaul@FreeBSD.ORG (Bill Paul) In-Reply-To: Message from wpaul@FreeBSD.ORG (Bill Paul) of "Sat, 12 Nov 2005 04:36:01 GMT." <20051112043601.9077C16A420@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Nov 2005 10:08:39 +0200 From: Danny Braniss Message-ID: Cc: freebsd-current@freebsd.org, Vulpes Velox Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 08:08:42 -0000 > > On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) > > wpaul@FreeBSD.ORG (Bill Paul) wrote: > > > > > > Ran into a few problems with ndisgen today. > > > > > > > > I have to edit every instance of the following out to get it to > > > > convert. > > > > Magic Packet = "Magic Packet" > > > > Pattern Match = "Pattern Match" > > > > Mag Pack Patt Match = "Magic Packet & Pattern Match" > > > > Link Change = "Link Change" > > > > > > > > > > > > Upon loading the driver I get... > > > > no match for ExUnregisterCallback > > > > no match for ZwPowerInformation > > > > no match for ExRegisterCallback > > > > no match for ExCreateCallback > > > > no match for ZwUnmapViewOfSection > > > > no match for ZwMapViewOfSection > > > > no match for ZwOpenSection > > > > no match for wcslen > > > > > > > > Any chance of getting this working or any suggestions? > > > > > > > > > > Ok, had I read the subject line of your mail fully I'd have known > > > what driver it was. I'm a dolt and I've clearly had too long of a > > > day. > > > > > > Here are the problems: > > > > > > - I don't know exactly what driver image you have. Unless you > > > provide the URL for where you got it to put a copy somewhere, > > > I can't really analyze it. > > > > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 > > > > IIRC the installer dumps it Program Files/Marvell It is where I > > grabbed the .sys and . > > I can probably unscramble it with Wine. I've had pretty good luck > with it with other driver distribution. > > > > - The .inf parser is not perfect. It's actually much stricter > > > about syntax than Windows is. Stuff that works ok for Windows > > > may be flagged as a syntax error by ndiscvt. If someone wants > > > to help fix this, they're welcome to. (No kernel hacking > > > required.) > > > > Cool, any suggested reads? > > The Microsoft MSDN site is the canonical source for documentation, > such as it is. I would start with something like: > > http://www.microsoft.com/whdc/archive/W2inf.mspx > > The .INF syntax is very subtle: it's evolved a lot over time and > you can use it to produce many strange effects. For example, it's > possible to create a .INF file that can figure out if you're on > a Win98, Win2K or WinXP system and install a different driver for > each one. Another major source of complication is registry key > specifications. NDIS drivers tend to specify only a few keys that > need to be created at install time, but it's possible to create > large numbers of them for various purposes. I've seen a Conexant > modem driver that uses its .INF file to store a bunch of special > keys containing some kind of binary patch tables that are used by > the driver at runtime. There's also different patch tables for > different chipsets. > > > > - I have no earthy idea why Marvell is referencing these functions > > > in their driver. They're totally outside the NDIS spec. I'd be > > > rather surprised that such a driver was able to get WHQL > > > certification. (Assuming it did.) > > Some investigation shows that they're probably using ExRegisterCallback() > and its ilk to obtain notification about power state events. And I > think they're using ZwMapViewOfSection() to basically do 'vtophys(),' > i.e. map a physical address to a virtual one, probably so they can > access some card resident RAM that's mapped into the host. (Actually, > ZwMapViewOfSection() lets you read from the \Devices\PhysicalMemory > device, so really it's the equivalent of grovelling around in /dev/mem.) > > I'm unsure why they're doing this. I was under the impression you > were supposed to have a MiniportPnpEvent() method to handle power > event notifications. As for the physical/virtual address translation > thing, they could have used NdisMMapIoSpace() or maybe even > MmMapIoSpace() instead. Who knows. > > > > - This is Marvell. Given the rotten treatment I've had from them > > > in the past, I'm not inclined to do them any favors now, so I'm > > > not exactly inclined to fix this anytime soon. > > > > Fun, what happened, if I may ask? > > Back when the patches to support the Yukon with sk(4) were first > merged in, and people were having problems with multicast, I asked > one of my SysKonnect contacts (who had now been assimilated by Marvell) > for the Yukon manuals so I could fix it. They told me that I would > need to sign both an NDA, and a software license agreement. I thought > this was strange since I wasn't licensing them my software and they > weren't licensing me theirs, but I told them I wanted official > recognition of the fact that this was an open source project and > that's what they came up with. I said "ok, send me both documents so > I can read them." They sent me the NDA, but not the software license > agreement. I wanted both before I would sign anything, and kept > prodding my contact to send the license agreement, but he kept begging > off and promising to talk with the right people. > > Finally after about a month of this, I finally got an e-mail from > someone else telling me that they had decided they were going to produce > their own binary driver (actually, they had been working on it all > along) and because of that they saw no need to give me the manuals > now. But they did offer me some free sample cards. > > I told them I was terminating any further involvement with SysKonnect > and Marvell and they could keep their cards. > > I still have the e-mails from them archived somewhere. > > Some time later (I'm not sure how long, maybe a month or two), I was > contacted via e-mail by a SysKonnect/Marvell engineer in Germany who > wanted to know if we could make the sk(4) driver optional so that their > customers could use their binary only driver without having to recompile > the kernel. I told him flatly that I wasn't on speaking terms with his > company anymore and that he was out of luck. > > I was startled to receive a phone call from him shortly after. He was > rather taken aback and curious to know why I had become so unhappy > with his company, so I explain to him how his Marvell overlords had > stonewalled me earlier. He was very surprised and disappointed. He > seemed like a nice fellow and I told him while I had nothing against > him personally, but I was not about to make Marvell's life easier when > they had made mine so miserable. > > During our conversation, I found out that he had been tasked with > developing the Yukon driver for FreeBSD. Then it was my turn to be > taken aback, when he admitted to me that he hadn't actually read > the Yukon manual: instead, he had been provided with an API library > for communicating with the card and was essentially producing a > wrapper for that library to interface it with FreeBSD. Now, this > technique is not new: Broadcom and other vendors have been using it > for a long time. But even so, I would like to think that library or > no, the engineers writing the drivers are actually familiar with the > hardware. > > So you can understand why I'm not in any hurry to do anything nice > for them. some months ago, using some local contacts, i managed to get from them the driver for the newer Yukon, after a long delay of QA. I tried it and it bombed. So after some exchanges, it seems that QA did not check it under SMP, even if the testing host was a dual cpu. They promised to have a newer in a few weeks, it's been now more than a few months. danny From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 11:02:35 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1AA716A41F for ; Sat, 12 Nov 2005 11:02:35 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3C2943D49 for ; Sat, 12 Nov 2005 11:02:34 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029493.msg for ; Sat, 12 Nov 2005 17:02:25 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127198, updated: 10.11.2005] To: Pete Carah References: <437535E4.2010400@altadena.net> From: Victor Snezhko Date: Sat, 12 Nov 2005 17:02:23 +0600 In-Reply-To: <437535E4.2010400@altadena.net> (Pete Carah's message of "Fri, 11 Nov 2005 16:23:00 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Sat, 12 Nov 2005 17:02:25 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: current@freebsd.org X-VVS-Spam: false Cc: current@freebsd.org Subject: Re: Crash using tun device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 11:02:35 -0000 Pete Carah writes: > I now (cvsup as of a day ago, and also from a week ago) see a > spontaneous reboot when using the tun device from userland ppp. This > occurs with either umodem or an ssh tunnel on the serial side, and > crashes immediately after the IP addresses are set. I don't know if it > is in route setting or not; the ssh tunnel script doesn't set the > default route via the tunnel (shoot self in foot, anyone?). There is a known bug in netinet6 that might cause this behaviour (although, I didn't see reboots, only panics). The fix is known but has not been committed yet. Here it is: --- netinet6/mld6.c Wed Nov 9 08:27:14 2005 *************** *** 640,645 **** --- 640,649 ---- mld6_stop_listening(in6m); ifma->ifma_protospec = NULL; LIST_REMOVE(in6m, in6m_entry); + if (in6m->in6m_timer != IN6M_TIMER_UNDEF) + mld_stoptimer(in6m); free(in6m->in6m_timer_ch, M_IP6MADDR); free(in6m, M_IP6MADDR); } > I didn't see this a month or two ago afaik, though it has been a while > since I had to use ppp on either laptop. The bug I mentioned was committed on Oct 21. If the fix don't help, try to disable INET6 and see if that helps. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 15:12:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6683316A41F for ; Sat, 12 Nov 2005 15:12:59 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE52843D4C for ; Sat, 12 Nov 2005 15:12:58 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 35949186 for multiple; Sat, 12 Nov 2005 08:22:31 -0700 Date: Sat, 12 Nov 2005 09:17:58 -0600 From: Vulpes Velox To: Jase Thew Message-ID: <20051112091758.448a12d6@vixen42.vulpes> In-Reply-To: <4375539F.6050405@beardz.net> References: <20051110212148.7a335fd9@vixen42.vulpes> <20051111054207.17ED516A421@hub.freebsd.org> <20051111190932.25ad86af@vixen42.vulpes> <4375539F.6050405@beardz.net> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-NotAscii: charset=us-ascii X-IP-stats: Incoming Last 0, First 40, in=68, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Cc: freebsd-current@freebsd.org Subject: Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 15:12:59 -0000 On Sat, 12 Nov 2005 02:29:51 +0000 Jase Thew wrote: > Vulpes Velox wrote: > > On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) > > > > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 > > > > IIRC the installer dumps it Program Files/Marvell It is where I > > grabbed the .sys and . > > > > Hi, > > I'd suggest trying these drivers instead : > > http://marvell.com/drivers/driverDisplay.do?dId=116&pId=3 > > These are the Yukon GigE NDIS5.1 miniport drivers for Windows XP, > and I have a feeling you'll have better luck with these. ndisgen fails on it as well. I will take a look at it later, but I am expecting to find similar problems with the inf as I had with the other. From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 15:24:35 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 023E016A420 for ; Sat, 12 Nov 2005 15:24:35 +0000 (GMT) (envelope-from lists@hosting50.cz) Received: from ares.strahov.cz (wireless.blueboard.cz [82.208.31.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D409143D4C for ; Sat, 12 Nov 2005 15:24:32 +0000 (GMT) (envelope-from lists@hosting50.cz) Received: (qmail 53646 invoked by uid 89); 12 Nov 2005 15:24:49 -0000 Received: by simscan 1.1.0 ppid: 53640, pid: 53642, t: 3.1624s scanners: clamav: 0.83/m:30/d:774 spam: 3.0.2 Received: from unknown (HELO ?192.168.1.97?) (postmaster@ares.strahov.cz@192.168.1.97) by ares.strahov.cz with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Nov 2005 15:24:46 -0000 Message-ID: <43760926.3090604@hosting50.cz> Date: Sat, 12 Nov 2005 16:24:22 +0100 From: Tomas Randa User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ServerWorks HT1000 experience? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 15:24:35 -0000 Hello! I would buy new SuperMicro motherboard H8SSL-i / http://www.supermicro.com/Aplus/motherboard/Opteron/HT1000/H8SSL-i.cfm / based on ServerWorks HT1000 Chipset. Is anybody here who tested these new chipsets HT1000 / HT2000 with FreeBSD ? Thanks for your answers. Tomas Randa From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 18:23:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BA5316A41F for ; Sat, 12 Nov 2005 18:23:44 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 468F743D45 for ; Sat, 12 Nov 2005 18:23:44 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jACINhdm004306; Sat, 12 Nov 2005 10:23:43 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jACINhb2004305; Sat, 12 Nov 2005 10:23:43 -0800 (PST) (envelope-from rizzo) Date: Sat, 12 Nov 2005 10:23:43 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20051112102343.A4222@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: struct timeval tv_sec type mismatch ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 18:23:44 -0000 on freebsd 5.x and above, the tv_sec field of struct timeval has type 'long' (defined here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/_timeval.h whereas apparently most platform have it as time_t, and i believe there are standards that require that: http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/time.h.html Any reason to keep it as a 'long' ? The differences between these two types prevents from passing &tv.tv_sec to functions requiring a time_t * as arguments, which is apparently a relatively common practice. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 18:35:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDAD216A41F; Sat, 12 Nov 2005 18:35:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 831A243D45; Sat, 12 Nov 2005 18:35:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jACIZtEn082614; Sat, 12 Nov 2005 13:35:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id jACIZuWL013629; Sat, 12 Nov 2005 13:35:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E2CE37302F; Sat, 12 Nov 2005 13:35:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051112183555.E2CE37302F@freebsd-current.sentex.ca> Date: Sat, 12 Nov 2005 13:35:55 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 18:35:58 -0000 TB --- 2005-11-12 17:19:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-11-12 17:19:04 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-11-12 17:19:04 - cleaning the object tree TB --- 2005-11-12 17:19:12 - checking out the source tree TB --- 2005-11-12 17:19:12 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-11-12 17:19:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-11-12 17:25:33 - building world (CFLAGS=-O2 -pipe) TB --- 2005-11-12 17:25:33 - cd /src TB --- 2005-11-12 17:25:33 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-11-12 18:29:30 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-11-12 18:29:30 - cd /src TB --- 2005-11-12 18:29:30 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Nov 12 18:29:30 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/fb/fb.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/fb/splash.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/fe/if_fe_cbus.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/io/iodev.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/kbd/kbd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/lnc/if_lnc_cbus.c /src/sys/dev/lnc/if_lnc_cbus.c: In function `lnc_isa_attach': /src/sys/dev/lnc/if_lnc_cbus.c:265: warning: comparison is always false due to limited range of data type *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-11-12 18:35:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-11-12 18:35:55 - ERROR: failed to build generic kernel TB --- 2005-11-12 18:35:55 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 19:21:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A984D16A41F for ; Sat, 12 Nov 2005 19:21:44 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4386E43D45 for ; Sat, 12 Nov 2005 19:21:44 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by xproxy.gmail.com with SMTP id t10so1314945wxc for ; Sat, 12 Nov 2005 11:21:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kkaHkVcTgtgUW7gG/faea72/HbfAAfvavGbtUdAjs/JmXnaxOaNMz4ukHx0JtY4AlH3MKH5bTaNd0bNfaif3CNRHBmfbJo/3tFvPpj/irR5Vf8IdMcK44Ybd+Uv0wknTf9u6pzxvQYM4hH+HL6bv753aIDEWQF7L9+3jEKjXSD4= Received: by 10.64.193.9 with SMTP id q9mr954455qbf; Sat, 12 Nov 2005 10:55:03 -0800 (PST) Received: by 10.64.21.5 with HTTP; Sat, 12 Nov 2005 10:55:03 -0800 (PST) Message-ID: Date: Sun, 13 Nov 2005 02:55:03 +0800 From: Xin LI To: Luigi Rizzo In-Reply-To: <20051112102343.A4222@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051112102343.A4222@xorpc.icir.org> Cc: current@freebsd.org Subject: Re: struct timeval tv_sec type mismatch ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2005 19:21:44 -0000 T24gMTEvMTMvMDUsIEx1aWdpIFJpenpvIDxyaXp6b0BpY2lyLm9yZz4gd3JvdGU6Cj4gb24gZnJl ZWJzZCA1LnggYW5kIGFib3ZlLCB0aGUgdHZfc2VjIGZpZWxkIG9mIHN0cnVjdCB0aW1ldmFsCj4g aGFzIHR5cGUgJ2xvbmcnIChkZWZpbmVkIGhlcmU6Cj4KPiAgICAgICAgaHR0cDovL3d3dy5mcmVl YnNkLm9yZy9jZ2kvY3Zzd2ViLmNnaS9zcmMvc3lzL3N5cy9fdGltZXZhbC5oCj4KPiB3aGVyZWFz IGFwcGFyZW50bHkgbW9zdCBwbGF0Zm9ybSBoYXZlIGl0IGFzIHRpbWVfdCwgYW5kIGkgYmVsaWV2 ZQo+IHRoZXJlIGFyZSBzdGFuZGFyZHMgdGhhdCByZXF1aXJlIHRoYXQ6Cj4KPiBodHRwOi8vd3d3 Lm9wZW5ncm91cC5vcmcvb25saW5lcHVicy8wMDk2OTUzOTkvYmFzZWRlZnMvc3lzL3RpbWUuaC5o dG1sCj4KPiBBbnkgcmVhc29uIHRvIGtlZXAgaXQgYXMgYSAnbG9uZycgPwoKQSBxdWljayBnb29n bGUgc2VhcmNoIGluZGljYXRlcyB0aGF0IHRoZSBvbmx5IHJlYXNvbiBpcyB0byBiZQpjb21wYXRp YmxlIHdpdGggVHJ1NjQgb24gQWxwaGEuWzFdCgpbMV0gaHR0cDovL2xpc3RzLmZyZWVic2Qub3Jn L3BpcGVybWFpbC9mcmVlYnNkLWhhY2tlcnMvMjAwNS1PY3RvYmVyLzAxMzk1Ni5odG1sCgpDaGVl cnMsCi0tClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5l dAo= From owner-freebsd-current@FreeBSD.ORG Sat Nov 12 17:51:39 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A256F16A41F for ; Sat, 12 Nov 2005 17:51:39 +0000 (GMT) (envelope-from hopet@ics.muni.cz) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D5AC43D53 for ; Sat, 12 Nov 2005 17:51:38 +0000 (GMT) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK ([83.210.44.6]) (user=hopet@META mech=LOGIN bits=0) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id jACHnexG011026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 12 Nov 2005 18:51:33 +0100 From: "Petr Holub" To: Date: Sat, 12 Nov 2005 18:51:30 +0100 Message-ID: <003701c5e7b1$b646d450$5317fb93@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Virus-Test: Clean X-Mailman-Approved-At: Sat, 12 Nov 2005 20:20:27 +0000 Cc: Subject: FW: [PATCH] MPEG2-TS patch for fwcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Nov 2005 17:51:39 -0000 Hi, do you think it would be worth commiting the following patches for fwcontrol to be able to receive HDV (MPEG2) streams? Thanks, Petr -----Original Message----- From: Petr Holub [mailto:hopet@ics.muni.cz] Sent: Tuesday, November 08, 2005 4:18 PM To: John-Mark Gurney Cc: multimedia@freebsd.org Subject: RE: [PATCH] MPEG2-TS patch for fwcontrol > Looks good, though you have a number of lines, both in the man page > and in source that are over 80 columns... also, a quick pass after > reading style(9) would be good... (variables aren't sorted properly > in mpegtsrecv, else not on same line as brace, spaces around if missing).. > you might want to update the year of the copyright :) OK, I've tried to stylify the patches and the new version are again available here: for 5.x: http://sitola.fi.muni.cz/~hopet/HDV/fwcontrol.patch for 6.x: http://sitola.fi.muni.cz/~hopet/HDV/fwcontrol-6.0.patch > Otherwise looks good... Have you looked at being able to send MPEG2-TS? > I wonder if it'd work w/ a DVHS deck, or a firewire capable HDTV tuner > like the Samsung SIR-T165... Sending - not yet. It's a little bit more complicated process because of the rules for data packetization on FireWire. As for the DVHS decks, I don't have any so I can't try that. The functionality of the patches has been verified using both SONY cameras mentioned in my previous mail. Petr ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-549493944 fax: +420-541212747 e-mail: hopet@ics.muni.cz