From owner-freebsd-stable@FreeBSD.ORG Sun Feb 22 01:30:05 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB5A1065672 for ; Sun, 22 Feb 2009 01:30:05 +0000 (UTC) (envelope-from tonymaher@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 37A608FC1C for ; Sun, 22 Feb 2009 01:30:04 +0000 (UTC) (envelope-from tonymaher@optusnet.com.au) Received: from karma.home (c58-107-102-243.thorn1.nsw.optusnet.com.au [58.107.102.243]) (authenticated sender tonymaher) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1M1U3Yk022076 for ; Sun, 22 Feb 2009 12:30:03 +1100 Message-ID: <49A0AAA2.7030104@optusnet.com.au> Date: Sun, 22 Feb 2009 12:30:10 +1100 From: Tony Maher User-Agent: Thunderbird 2.0.0.19 (X11/20090219) MIME-Version: 1.0 To: stable@freebsd.org References: <4971B18D.3090803@optusnet.com.au> In-Reply-To: <4971B18D.3090803@optusnet.com.au> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 7.1 Release and usb keyboard/mouse problems (and Xorg) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:30:06 -0000 Tony Maher wrote: > Hello, > > I have been running FreeBSD 7 from around 2008-10-20 and experienced > the occasional problems with usb mouse and keyboard. The mouse pointer > slowly drift to a corner of the screen and not respond, and the keyboard > would become unresponsive. Unplugging and plugging back in fixed the > problem. > This would happen a few times per week. > > However after I upgraded to 7.1-RELEASE-p2, I now get this problem > every few hours if idle (hard to know exactly when it occurs since i am > not at keyboard) and a few minutes if doing a background compilation. > The keyboard often shows one of the LEDs constantly flashing at high speed. > Unplugging and replugging often does not work and needs to be done > several times (and use a different usb port). > > I saw some email reports and tried in /boot/device.hints > hint.atkbd.0.disable="1" > hint.atkbdc.0.disable="1" > > No change. > > Tried a different mouse and it would continue to work but my normal mouse > would disconnect. Tried an identical keyboard and it exhibited the same > problem ruling out a bad keyboard. I then tried another keyboard and > have not had any problem since. > > The main thing I can see different is the working keyboard is a Logitech > and the two problematic keyboards are (very) cheap noname keyboards. > Both the mice are Logitech but the mouse that has problems is very old > (from around year 2000 - model M-BA47). The working mouse is newer but > still fairly old (Model M-UV96). > > The box is a amd64 with Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GH > 4GB RAM and motherboard is Intel DP35DP. > > So my setup now appears to be fine. If anyone is having similar problems, > I suggest trying different (more modern) mice/keyboards. Unfotunately things got worse after more port upgrades. With Xorg 7.4 and gnome could not even get the logon screen - just a busy cursor. The Xorg.0.log had a message like (EE) Logitech USB Keyboard: cannot open "/dev/ukbd0" (EE) PreInit failed for input device "Logitech USB Keyboard" (II) UnloadModule: "kbd" which made me think this was the problem. However I now have everything working fine and still get this message. Reverting X and gnome back and applications like xterms were slow to start up plus mouse was slow to respond. Tried lots of options but in the end gave up and went for a clean install of 7.1 (First time I have ever had to do this in over 10 years of using FreeBSD!) Everything worked pretty good. Did a cvsup and upgraded everything and all works fine. The only problems I did encounter were/are: 1. my xorg.conf options were ignored Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbOptions" "ctrl:nocaps" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection /var/log/Xorg.0.log shows (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. Not sure why this is. Man page says Option "AllowEmptyInput" "boolean" If enabled, don't add the standard keyboard and mouse drivers, if there are no input devices in the config file. Enabled by default if AutoAddDevices and AutoEnableDevices is enabled, oth- erwise disabled. If AllowEmptyInput is on, devices using the kbd or mouse driver are ignored. It is not set in my xorg.conf and neither are Auto* directives. ~:255 egrep 'Auto|Allow' /usr/local/etc/X11/xorg.conf ~:256 To get the ctrl:nocaps used the gnome keyboard setting tool. Mouse works fine except the side button does no work and fixed that by adding moused_flags="-m2=4" to rc.conf. 2. gxine after upgrade would always segmentation fault. I used portupgrade -y -m BATCH=true gxine and this appears to be the problem. I rebuilt using make config selecting all options except lirc support. Did portupgrade -w -W gxine and it now works fine. 3. At some point along the line I (re)discovered the 'fc-cache -f -v' which fixed slow xterm startup. I tried plugging in the old keyboard and mouse along side the more modern ones I have been using since the problems started and they appear to be ok. I was using the old mouse but the new keyboard (with the other two still attached). I was going to say they worked fine but just before the start of this paragraph I started to get '9' repeated across the screen and the keyboard was unresponsive. I had also just powered up a USB drive a few minutes before this happened but I had run with this configuration all day yesterday without problems.. I have removed the older keyboard and mouse for now. I was thinking maybe my problems stemmed from having two moused running one from system start up and the other from hald but do not have any output from the old system to confirm this was happening. At this point everything is working perfectly. I read someones advice who said make a copy or /usr/local and /var/db/pkg before undertaking major port subsystem upgrades. I think this is an excellent idea! cheers -- Tony Maher email: tonymaher@optusnet.com.au From owner-freebsd-stable@FreeBSD.ORG Sun Feb 22 04:15:02 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C89F8106564A for ; Sun, 22 Feb 2009 04:15:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFAA8FC13 for ; Sun, 22 Feb 2009 04:15:02 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.2] (adsl-157-36-144.bna.bellsouth.net [70.157.36.144]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n1M4DavK085077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 23:13:36 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Tony Maher In-Reply-To: <49A0AAA2.7030104@optusnet.com.au> References: <4971B18D.3090803@optusnet.com.au> <49A0AAA2.7030104@optusnet.com.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gUW/13wlAIQVZV0HSGdE" Organization: FreeBSD Date: Sat, 21 Feb 2009 22:14:51 -0600 Message-Id: <1235276091.1278.77.camel@widget.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org Subject: Re: 7.1 Release and usb keyboard/mouse problems (and Xorg) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 04:15:03 -0000 --=-gUW/13wlAIQVZV0HSGdE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-02-22 at 12:30 +1100, Tony Maher wrote: > Tony Maher wrote: > > Hello, > >=20 > > I have been running FreeBSD 7 from around 2008-10-20 and experienced > > the occasional problems with usb mouse and keyboard. The mouse pointer > > slowly drift to a corner of the screen and not respond, and the keyboar= d > > would become unresponsive. Unplugging and plugging back in fixed the=20 > > problem. > > This would happen a few times per week. > >=20 > > However after I upgraded to 7.1-RELEASE-p2, I now get this problem > > every few hours if idle (hard to know exactly when it occurs since i am= =20 > > not at keyboard) and a few minutes if doing a background compilation. > > The keyboard often shows one of the LEDs constantly flashing at high sp= eed. > > Unplugging and replugging often does not work and needs to be done=20 > > several times (and use a different usb port). > >=20 > > I saw some email reports and tried in /boot/device.hints > > hint.atkbd.0.disable=3D"1" > > hint.atkbdc.0.disable=3D"1" > >=20 > > No change. > >=20 > > Tried a different mouse and it would continue to work but my normal mou= se > > would disconnect. Tried an identical keyboard and it exhibited the sam= e > > problem ruling out a bad keyboard. I then tried another keyboard and=20 > > have not had any problem since. > >=20 > > The main thing I can see different is the working keyboard is a Logitec= h > > and the two problematic keyboards are (very) cheap noname keyboards. > > Both the mice are Logitech but the mouse that has problems is very old > > (from around year 2000 - model M-BA47). The working mouse is newer but > > still fairly old (Model M-UV96). > >=20 > > The box is a amd64 with Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GH > > 4GB RAM and motherboard is Intel DP35DP. > >=20 > > So my setup now appears to be fine. If anyone is having similar proble= ms, > > I suggest trying different (more modern) mice/keyboards. >=20 > Unfotunately things got worse after more port upgrades. > With Xorg 7.4 and gnome could not even get the logon screen - just a busy= cursor. > The Xorg.0.log had a message like > (EE) Logitech USB Keyboard: cannot open "/dev/ukbd0" > (EE) PreInit failed for input device "Logitech USB Keyboard" > (II) UnloadModule: "kbd" > which made me think this was the problem. However I now have everything > working fine and still get this message. This should generally be harmless. It is because kbdmux has already grabbed ukbd and then hald is advertising the ukbd device to xorg. xorg fails to open the device, but is still talking to it via kbdmux. > Reverting X and gnome back and applications like xterms were slow > to start up plus mouse was slow to respond. Tried lots of options but in= the end gave > up and went for a clean install of 7.1 (First time I have ever had to do = this > in over 10 years of using FreeBSD!) >=20 > Everything worked pretty good. > Did a cvsup and upgraded everything and all works fine. > The only problems I did encounter were/are: >=20 > 1. my xorg.conf options were ignored >=20 > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbOptions" "ctrl:nocaps" > EndSection >=20 > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection >=20 >=20 > /var/log/Xorg.0.log shows >=20 > (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will b= e disabled. >=20 > Not sure why this is. Man page says > Option "AllowEmptyInput" "boolean" > If enabled, don't add the standard keyboard and mouse driv= ers, > if there are no input devices in the config file. Enabled= by > default if AutoAddDevices and AutoEnableDevices is enabled, = oth- > erwise disabled. If AllowEmptyInput is on, devices using = the > kbd or mouse driver are ignored. >=20 > It is not set in my xorg.conf and neither are Auto* directives. > ~:255 egrep 'Auto|Allow' /usr/local/etc/X11/xorg.conf > ~:256=20 These are on by default now and the server uses hald to detect keyboard and mouse. If you don't want to use hald, set Option "AutoAddDevices" "off" and it will use your configured devices. robert. > To get the ctrl:nocaps used the gnome keyboard setting tool. > Mouse works fine except the side button does no work and fixed that by ad= ding > moused_flags=3D"-m2=3D4" to rc.conf. >=20 > 2. gxine after upgrade would always segmentation fault. > I used portupgrade -y -m BATCH=3Dtrue gxine and this appears to be the = problem. > I rebuilt using make config selecting all options except lirc support. > Did portupgrade -w -W gxine and it now works fine. >=20 > 3. At some point along the line I (re)discovered the 'fc-cache -f -v' > which fixed slow xterm startup. >=20 > I tried plugging in the old keyboard and mouse along side the more modern= ones > I have been using since the problems started and they appear to be ok. > I was using the old mouse but the new keyboard (with the other two still = attached). > I was going to say they worked fine but just before the start of this par= agraph > I started to get '9' repeated across the screen and the keyboard > was unresponsive. I had also just powered up a USB drive a few minutes b= efore this > happened but I had run with this configuration all day yesterday without = problems.. > I have removed the older keyboard and mouse for now. >=20 > I was thinking maybe my problems stemmed from having two moused running > one from system start up and the other from hald but do not have any outp= ut > from the old system to confirm this was happening. >=20 > At this point everything is working perfectly. >=20 > I read someones advice who said make a copy or /usr/local and /var/db/pkg > before undertaking major port subsystem upgrades. I think this is an exce= llent > idea! >=20 >=20 > cheers --=20 Robert Noland FreeBSD --=-gUW/13wlAIQVZV0HSGdE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmg0TsACgkQM4TrQ4qfRON7zACZAcKDik1aWKhoCc9vlNaY+jIA ah0An1C5A51MSv3blmjNTfBW8sGuiXvi =hIO6 -----END PGP SIGNATURE----- --=-gUW/13wlAIQVZV0HSGdE-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 22 20:33:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7E7E1065675 for ; Sun, 22 Feb 2009 20:33:00 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5060E8FC08 for ; Sun, 22 Feb 2009 20:33:00 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 9BB90301C4; Sun, 22 Feb 2009 21:32:57 +0100 (CET) Date: Sun, 22 Feb 2009 21:32:57 +0100 From: cpghost To: freebsd-stable@freebsd.org Message-ID: <20090222203257.GA7647@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: buildworld broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:33:01 -0000 Who broken RELENG_7 (as of Feb 22 18:24 UTC)? ===> usr.sbin/ifmcstat (all) cc -O2 -fno-strict-aliasing -pipe -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/ ifmcstat.c /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs': /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use in this function) /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i n.) *** Error code 1 Stop in /usr/src/usr.sbin/ifmcstat. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 22 20:51:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0AE01065672 for ; Sun, 22 Feb 2009 20:51:10 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8EC8FC0C for ; Sun, 22 Feb 2009 20:51:10 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 5B93C301C4; Sun, 22 Feb 2009 21:51:06 +0100 (CET) Date: Sun, 22 Feb 2009 21:51:05 +0100 From: cpghost To: freebsd-stable@freebsd.org Message-ID: <20090222205105.GB7647@phenom.cordula.ws> References: <20090222203257.GA7647@phenom.cordula.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090222203257.GA7647@phenom.cordula.ws> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: buildworld broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:51:11 -0000 On Sun, Feb 22, 2009 at 09:32:57PM +0100, cpghost wrote: > Who broken RELENG_7 (as of Feb 22 18:24 UTC)? > > ===> usr.sbin/ifmcstat (all) > cc -O2 -fno-strict-aliasing -pipe -DINET6 -DWITH_KVM -Wsystem-headers -Wall -Wn > o-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/ifmcstat/ > ifmcstat.c > /usr/src/usr.sbin/ifmcstat/ifmcstat.c: In function 'ifmcstat_getifmaddrs': > /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: 'pllasa' undeclared (first use > in this function) > /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: (Each undeclared identifier is > reported only once > /usr/src/usr.sbin/ifmcstat/ifmcstat.c:771: error: for each function it appears i > n.) > *** Error code 1 > > Stop in /usr/src/usr.sbin/ifmcstat. > *** Error code 1 Nevermind, it is probably already fixed: http://lists.freebsd.org/pipermail/svn-src-stable/2009-February/000854.html Sorry for the noise. Rebuilding world now... ;) -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 01:30:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D96F106566B for ; Mon, 23 Feb 2009 01:30:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 969438FC16 for ; Mon, 23 Feb 2009 01:30:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1N1Ueo6084489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 12:00:40 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 23 Feb 2009 12:00:30 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2141986.bPZGNLoyN5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902231200.38164.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Intel Q45 problems on 7.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:30:45 -0000 --nextPart2141986.bPZGNLoyN5 Content-Type: multipart/mixed; boundary="Boundary-01=_3wfoJyQYFyreFOj" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_3wfoJyQYFyreFOj Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I recently got an Intel DQ45CB based system and I am trying to use the onbo= ard=20 video. Initially it hung solid when X started, however when I reduced the amount o= f=20 RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text conso= le=20 and back to X then the machine locks solid (no numlock, have to hard reset). I note that dmesg reports 32764k of stolen memory, however I set the DVMT R= AM=20 to 128Mb (and 256Mb, makes no difference). Also the aperture size is always= =20 reported as 256Mb no matter what it actually is in the BIOS. I have disabled the glx & dri modules in xorg.conf (attached) and it seemed= to=20 work better for a bit but then crashed a little later. Currently I am stuck= =20 with VESA which is functional but a bit slow. I am using xorg 7.4 and I have a 7.1-STABLE from only a week ago, if anyone= =20 has some patches I'd be happy to test them :) dmesg & xorg.log are attached too. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Boundary-01=_3wfoJyQYFyreFOj Content-Type: text/plain; charset="utf-8"; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. =46reeBSD is a registered trademark of The FreeBSD Foundation. =46reeBSD 7.1-STABLE #0: Wed Feb 18 19:23:15 CST 2009 root@obtuse-2ng.gsoft.com.au:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz (2800.12-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x1067a Stepping =3D 10 Features=3D0xbfebfbff Features2=3D0x408e39d AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 2110783488 (2013 MB) avail memory =3D 2052956160 (1957 MB) ACPI APIC Table: =46reeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf220-0xf227 mem 0xd0000000-0xd03ff= fff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 32764k stolen memory agp0: aperture size is 256M vgapci1: mem 0xd0400000-0xd04fffff at device 2.1 o= n pci0 pci0: at device 3.0 (no driver attached) atapci0: port 0xf210-0xf217,0xf200-0xf203,0xf1f0-0xf= 1f7,0xf1e0-0xf1e3,0xf1d0-0xf1df irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0xf0e0-0xf0ff mem 0x= d0600000-0xd061ffff,0xd0624000-0xd0624fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:9d:2e:47 uhci0: port 0xf0c0-0xf0df irq 16 at device = 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xf0a0-0xf0bf irq 21 at device = 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xf080-0xf09f irq 18 at device = 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd0626400-0xd06267ff irq 18= at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: waiting for BIOS to give up control usb3: timed out waiting for BIOS usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered hdac0: mem 0xd0620000-0x= d0623fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] uhci3: port 0xf060-0xf07f irq 23 at device = 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xf040-0xf05f irq 19 at device = 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xf020-0xf03f irq 18 at device = 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd0626000-0xd06263ff irq 23= at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: waiting for BIOS to give up control usb7: timed out waiting for BIOS usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered umass0: on uhub7 pcib1: at device 30.0 on pci0 pci1: on pcib1 fwohci0: mem 0xd0500000-0xd0500fff,0xd0501000-0xd05010ff= irq 22 at device 1.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=3D0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:02:41:76:6b 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:90:27:41:76:6b fwe0: Ethernet address: 02:90:27:41:76:6b fwip0: on firewire0 fwip0: Firewire address: 00:90:27:00:02:41:76:6b @ 0xfffe00000000, S400, ma= xrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12e0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xf1b0-0xf1b7,0xf1a0-0xf1a3,= 0xf190-0xf197,0xf180-0xf183,0xf170-0xf17f,0xf160-0xf16f irq 19 at device 31= =2E2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xf150-0xf157,0xf140-0xf143,= 0xf130-0xf137,0xf120-0xf123,0xf110-0xf11f,0xf100-0xf10f irq 19 at device 31= =2E5 on pci0 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] acpi_button0: on acpi0 acpi_button1: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xcc800-0xcd7ff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd2 at ukbd0 uhid0: on uhub0 ums0: on uhub0 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) ad8: 238475MB at ata4-master SATA300 GEOM_LABEL: Label for provider ad8s1 is ntfs/XPPro. GEOM_LABEL: Label for provider ad8s2a is ufs/slash. GEOM_LABEL: Label for provider ad8s2d is ufs/var. GEOM_LABEL: Label for provider ad8s2e is ufs/usr. acd0: DVDR at ata5-master SATA150 hdac0: HDA Codec #2: Analog Devices AD1882 hdac0: Adding 58 (nid=3D35): Max connection reached! max=3D32 pcm0: at cad 2 nid 1 on hdac0 pcm1: at cad 2 nid 1 on hdac0 SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device=20 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device=20 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device=20 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device=20 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ufs/slash WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 20 files 3 WARNING: /var was not properly dismounted /var: mount pending error: blocks 48 files 0 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted --Boundary-01=_3wfoJyQYFyreFOj Content-Type: text/plain; charset="utf-8"; name="xorg.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xorg.conf" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "ServerFlags"=20 Option "AllowEmptyInput" "off"=20 Option "AutoAddDevices" "off"=20 EndSection=20 Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" #Load "glx" Disable "glx" Load "xtrap" #Load "dri" Disable "dri" Load "freetype" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "ColorKey" # #Option "CacheLines" # #Option "Dac6Bit" # [] #Option "DRI" # [] #Option "NoDDC" # [] #Option "ShowCache" # [] #Option "XvMCSurfaces" # #Option "PageFlip" # [] Identifier "Card0" #Driver "intel" Driver "vesa" VendorName "Intel Corporation" BoardName "4 Series Chipset Integrated Graphics Controller" BusID "PCI:0:2:0" Option "DRI" "False" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection --Boundary-01=_3wfoJyQYFyreFOj-- --nextPart2141986.bPZGNLoyN5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJofw35ZPcIHs/zowRAlaBAJ429ufSuVBQd8FFLnqBLTVKpf2uGgCgowJb jkV+WfzGdYwo96vmhADo2yA= =WlyU -----END PGP SIGNATURE----- --nextPart2141986.bPZGNLoyN5-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 06:20:26 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B605106566B; Mon, 23 Feb 2009 06:20:26 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id AAE8E8FC0C; Mon, 23 Feb 2009 06:20:25 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1N63LT7071155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 22:03:22 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A23C1A.3070403@FreeBSD.org> Date: Sun, 22 Feb 2009 22:03:06 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 06:20:26 -0000 Hi Jeff, I have a single-CPU system with P4 HTT-enabled processor (7.1-RELEASE-p3), kernel compiled with SCHED_ULE. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE-p3 #0: Fri Feb 20 09:53:32 UTC 2009 root@foo.com:/usr/obj/usr/src/sys/SSP-PRODUCTION7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d Logical CPUs per core: 2 real memory = 3758030848 (3583 MB) avail memory = 3674083328 (3503 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 2 If I flip machdep.hyperthreading_allowed sysctl, I still can see processes scheduled to both logical CPUs, yet, if I check IRQ status in the systat -vm, the CPU1 is not getting any timer interrupts, while CPU0 gets twice the normal amount. I wonder if something is broken - I would expect no processes to be scheduled to the CPU1. machdep.hyperthreading_allowed=1: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot458.png systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot459.png machdep.hyperthreading_allowed=0: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot460.png systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot461.png Please let me know if any other debug information is needed. -Maxim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 06:26:29 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6EF410656BB; Mon, 23 Feb 2009 06:26:29 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 87DE78FC1E; Mon, 23 Feb 2009 06:26:29 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-228-87.phil.east.verizon.net [70.20.228.87]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 8626A61B39; Mon, 23 Feb 2009 15:06:09 +0900 (JST) Date: Mon, 23 Feb 2009 01:06:04 -0500 From: Yoshihiro Ota To: Steve Wills , Daichi GOTO Message-Id: <20090223010604.fd404e45.ota@j.email.ne.jp> In-Reply-To: <499FCAD4.8000006@freebsd.org> References: <95E82F15-2535-4C67-BDF0-44CFC7EB9FBB@mouf.net> <499FCAD4.8000006@freebsd.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Masanori OZAWA Subject: Re: unionfs panic in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 06:26:30 -0000 On Sat, 21 Feb 2009 18:35:16 +0900 Daichi GOTO wrote: > Steve Wills wrote: > > Hi, > > > > I've found an reproducable panic in unionfs on 7.1-R. > > > > /usr/src/sys/fs/unionfs/union_subr.c is: > > $FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2 2008/12/15 > > 03:58:55 daichi Exp $ > > > > kgdb output is below. > > > > I reproduce this by unionfs mounting a ports dir used by the ports > > tinderbox. If anyone would like more info, please let me know, I have > > the core around, and can reproduce, help debug, resend in case my mailer > > has mangled this, etc. > > I have some research around that issue. > > First I should say, I cannot judge that unionfs leads > that problem or not. JIMO, I guess that is not depends > on unionfs itself. Very similar panis is reported without > unionfs. At least, I cannot figure out what is the main > cause of this problem. sorry. I wonder if it is one of LORs, http://sources.zabbadoz.net/freebsd/lor.html If you can try on 8-CURRENT and reproduce, it may provide you better info. Regards, Hiro From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 08:04:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B95E8106564A for ; Mon, 23 Feb 2009 08:04:21 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 28C148FC0A for ; Mon, 23 Feb 2009 08:04:20 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n1N84G1I036396; Mon, 23 Feb 2009 11:04:16 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 23 Feb 2009 11:04:16 +0300 (MSK) From: Dmitry Morozovsky To: Karl Denninger In-Reply-To: <499C4BFC.3050704@denninger.net> Message-ID: References: <4994CD7B.7040302@denninger.net> <499526E9.3090804@bit0.com> <2CA7DE699281AFA5DF2BD851@syn> <200902181728.16842.ianjhart@ntlworld.com> <499C4BFC.3050704@denninger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (woozle.rinet.ru [0.0.0.0]); Mon, 23 Feb 2009 11:04:16 +0300 (MSK) Cc: freebsd-stable@freebsd.org Subject: Re: Upgrade from 32-bit to AMD-64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:04:22 -0000 On Wed, 18 Feb 2009, Karl Denninger wrote: KD> I have been able to come up with a procedure that works. KD> KD> 1. Load a new hard disk with the 64-bit code. Perform a buildworld and KD> buildkernel, and installkernel and installworld to this disk to verify that KD> it will install and run. You now have a "base" disk to use for migration. KD> KD> 2. Make sure you have a backup (:-)) KD> KD> 3. Boot the migration hard disk as the system disk and mount the subject KD> machine's disk drive(s) under /mnt. KD> KD> 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt installworld" KD> KD> 5. Shut down and disconnect migration disk. KD> KD> 6. Boot SINGLE USER and verify that the system boots, you can fsck -p the KD> disks, and mount them. The system should boot and run. KD> KD> 7. Come up multiuser but with any services necessary to the world offline. KD> Some of your packages may blow up when started. If so, portupgrade SHOULD KD> fix it, but this is not consistent. I had to manually dump the ports tree KD> and rebuild a few installed ports due to what appear to be broken KD> dependancies, but not many. KD> KD> Postgresql 32-bit runs fine without recompilation after doing this. It is KD> arguably preferrable to recompile; doing so requires a dump/restore of the KD> data as the 32 and 64-bit code will NOT run off the same binary data store. KD> KD> Attempting to "make instalkernel" on an "in-place" basis resulted in a KD> system that booted but failed immediately due to loader conflicts; there was KD> no way to get the rest of the codeset loaded if you make that mistake. You can avoid most of these problems if you have copies of ld-elf (both 32-bit and 64-bit), and boot single user for /rescue; however, "migration disk" approach is much simpler. KD> KD> The "migration disk" approach appears to work fine. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 10:08:38 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2D4E106564A; Mon, 23 Feb 2009 10:08:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60C858FC15; Mon, 23 Feb 2009 10:08:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 057CE46B09; Mon, 23 Feb 2009 05:08:38 -0500 (EST) Date: Mon, 23 Feb 2009 10:08:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <49A23C1A.3070403@FreeBSD.org> Message-ID: References: <49A23C1A.3070403@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:08:39 -0000 On Sun, 22 Feb 2009, Maxim Sobolev wrote: > Hi Jeff, > > I have a single-CPU system with P4 HTT-enabled processor (7.1-RELEASE-p3), > kernel compiled with SCHED_ULE. This is because machdep.hlt_logical_cpus doesn't do what you think it does. It causes HTT cores to invoke the hlt instruction in their idle loop, causing them to sleep until they receive an interrupt. For 4BSD, which uses a "pull" model (on the whole) to bring work from work queues, this means that CPUs will go to sleep and remain that way unless they're actively receiving interrupts. For ULE, which uses "push" as well as "pull", threads will constantly be being shed from too-busy CPUs to apparently idle ones under load. The only reliable way to disable hyperthreading is to do so using your BIOS setting, or use loader.conf to disable probing of the pics on unwanted cores, which will cause the CPUs not to be enumerated and hence not used. We don't support taking CPUs fully offline with any scheduler, although you can use the cpuset facility to prevent threads from running on specific cores. You could imagine teaching ULE (and presumably 4BSD) about policies such as "Don't use HTT cores", or perhaps just cpuset about those policies. Robert N M Watson Computer Laboratory University of Cambridge > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-RELEASE-p3 #0: Fri Feb 20 09:53:32 UTC 2009 > root@foo.com:/usr/obj/usr/src/sys/SSP-PRODUCTION7 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 > > Features=0xbfebfbff > Features2=0x441d > Logical CPUs per core: 2 > real memory = 3758030848 (3583 MB) > avail memory = 3674083328 (3503 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 0 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 2 > > If I flip machdep.hyperthreading_allowed sysctl, I still can see processes > scheduled to both logical CPUs, yet, if I check IRQ status in the systat -vm, > the CPU1 is not getting any timer interrupts, while CPU0 gets twice the > normal amount. I wonder if something is broken - I would expect no processes > to be scheduled to the CPU1. > > machdep.hyperthreading_allowed=1: > top: http://sobomax.sippysoft.com/~sobomax/ScreenShot458.png > systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot459.png > > machdep.hyperthreading_allowed=0: > top: http://sobomax.sippysoft.com/~sobomax/ScreenShot460.png > systat -vm: http://sobomax.sippysoft.com/~sobomax/ScreenShot461.png > > Please let me know if any other debug information is needed. > > -Maxim > _______________________________________________ > 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-stable@FreeBSD.ORG Mon Feb 23 11:54:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2993F1065672 for ; Mon, 23 Feb 2009 11:54:14 +0000 (UTC) (envelope-from prvs=0305a14c0b=ob@gruft.de) Received: from obh.snafu.de (v6.gruft.de [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E71D8FC17 for ; Mon, 23 Feb 2009 11:54:13 +0000 (UTC) (envelope-from prvs=0305a14c0b=ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LbZO0-0004GV-Ou; Mon, 23 Feb 2009 12:54:12 +0100 Date: Mon, 23 Feb 2009 12:54:12 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20090223115412.GO79003@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org, Pyun YongHyeon References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> <20090213102400.GD12653@michelle.cdnetworks.co.kr> <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> <20090213113955.GE12653@michelle.cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213113955.GE12653@michelle.cdnetworks.co.kr> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Oliver Brandmueller Cc: Pyun YongHyeon Subject: Re: fun with if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:54:14 -0000 Hi, On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote: > Ok, try attached patch. > Index: sys/dev/re/if_re.c > =================================================================== > --- sys/dev/re/if_re.c (revision 187352) > +++ sys/dev/re/if_re.c (working copy) > @@ -158,6 +158,8 @@ > /* Tunables. */ [...] This seems to have fixed a regression I found after the latest re changes. While the changes lead to a situation, where the re interface (as opposed to before) seems to always attach, I had the problem that after 1-2 days it failed (sorry, was just about to investigate when I tried your patch and thus didn't write down the error message associated). With your patch my re seems to be running fine for the last days now. re0@pci0:4:0:0: class=0x020000 card=0x392c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 18 at device 0.0 on pci4 re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:85:1e:8b:c9 re0: [FILTER] - Oliver From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 12:03:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A33106590A for ; Mon, 23 Feb 2009 12:03:07 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id BCC018FC08 for ; Mon, 23 Feb 2009 12:03:07 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 151C92A247B; Mon, 23 Feb 2009 07:03:07 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 23 Feb 2009 07:03:07 -0500 X-Sasl-enc: OhH3GOgabwUcIJ3JIWIUNnnzEyl3HkXcvf6rjBhhH/6w 1235390586 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 875953256C; Mon, 23 Feb 2009 07:03:06 -0500 (EST) Message-ID: <49A29077.5040009@incunabulum.net> Date: Mon, 23 Feb 2009 12:03:03 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20090125) MIME-Version: 1.0 To: cpghost References: <20090222203257.GA7647@phenom.cordula.ws> In-Reply-To: <20090222203257.GA7647@phenom.cordula.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: buildworld broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:03:35 -0000 Already dealt with, I was merging a change by hand whilst hungover after a good party. ;^) Sorry for the churn. A lot of this stuff gets utterly demolished and rebuilt in the IGMPv3 snap. I don't plan to backport the multicast work ongoing in p4 to 7-STABLE without testers, and air-out in 8-CURRENT first. One of the reasons it's taken so long is because there has been a *lot* of network stack re-engineering in 8-CURRENT (VIMAGE, arpv2, multi-fib, IFF_NEEDSGIANT removal). ASM state changes are believed working, but that is dog simple... Right now my aim is to get SSM working in the p4 branch fully. The IGMPv3 bottom half code is all done with the VIMAGE hooks, it's just a case of making the SSM state change stuff behave right. cheers BMS From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 13:53:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C713106566B for ; Mon, 23 Feb 2009 13:53:44 +0000 (UTC) (envelope-from doug@polands.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA958FC12 for ; Mon, 23 Feb 2009 13:53:43 +0000 (UTC) (envelope-from doug@polands.org) Received: from haran.polands.org ([75.87.219.217]) by hrndva-omta01.mail.rr.com with ESMTP id <20090223133828.ZNHS20095.hrndva-omta01.mail.rr.com@haran.polands.org> for ; Mon, 23 Feb 2009 13:38:28 +0000 Received: from email.polands.org (moab.polands.org [172.16.1.8]) by haran.polands.org (8.14.3/8.14.3) with ESMTP id n1NDcSne025253 for ; Mon, 23 Feb 2009 07:38:28 -0600 (CST) (envelope-from doug@polands.org) Received: from 172.16.1.68 (SquirrelMail authenticated user djp) by email.polands.org with HTTP; Mon, 23 Feb 2009 07:38:28 -0600 (CST) Message-ID: <084becfc4478ca25081d8354e54f9b45.squirrel@email.polands.org> Date: Mon, 23 Feb 2009 07:38:28 -0600 (CST) From: "Doug Poland" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: amd64 installworld fails on syscons/scrnmaps X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:53:44 -0000 Hello, I have an amd64 laptop on which I did a fresh csup to RELENG_7. I did the canonical "buildworld", "buildkernel", "installkernel" and so far so good. However, when I attempt to "installworld", I get: ===> share/syscons/scrnmaps (install) ./armscii8-2haik8.mk armscii8-2haik8.tmp uuencode armscii8-2haik8.tmp armscii8-2haik8 > armscii8-2haik8.scm uuencode: not found *** Error code 127 Stop in /usr/src/share/syscons/scrnmaps. *** Error code 1 The binary uuencode exists in /usr/bin, as do the files: armscii8-2haik8.tmp armscii8-2haik8, armscii8-2haik8.scm in /usr/obj/usr/src/share/syscons/scrnmaps/ I have not rebooted since installing the new kernel and have tried installworld twice. Here's my /usr/local/etc/cvsup/sup/supfile: *default base=/var/db *default delete use-rel-suffix compress *default host=cvsup15.freebsd.org *default prefix=/usr *default release=cvs tag=RELENG_7 src-all Here's my /etc/make.conf and /etc/src.conf: make.conf: # added by use.perl 2009-02-23 03:20:27 PERL_VER=5.8.9 PERL_VERSION=5.8.9 src.conf: WITHOUT_PROFILE= Not sure how to diagnose or resolve this on my own and need a little assistance, please. -- Regards, Doug From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 14:05:54 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28FAE10656C4; Mon, 23 Feb 2009 14:05:54 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id E13538FC1E; Mon, 23 Feb 2009 14:05:53 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1NE5pDs095827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 06:05:52 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A2AD30.1040007@FreeBSD.org> Date: Mon, 23 Feb 2009 06:05:36 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <49A23C1A.3070403@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:05:55 -0000 Robert Watson wrote: > > On Sun, 22 Feb 2009, Maxim Sobolev wrote: > >> Hi Jeff, >> >> I have a single-CPU system with P4 HTT-enabled processor >> (7.1-RELEASE-p3), kernel compiled with SCHED_ULE. > > This is because machdep.hlt_logical_cpus doesn't do what you think it > does. It causes HTT cores to invoke the hlt instruction in their idle Hmm, as the subject says I am actually talking about flipping machdep.hyperthreading_allowed, not machdep.hlt_logical_cpus sysctl here. I provided current value of the latter only to simplify diagnosis and had not changed it from the default value. AFAIK, the machdep.hyperthreading_allowed is designed to prevent logical cores from running any code, works just fine with 6.x/SCHED_4BSD. Below are screenshots from the dual-core 6.2 system with 4BSD. As you can easily see, after flipping machdep.hyperthreading_allowed only cores 0 and 2 run actual code, so that it's definitely regression of ULE/7.x: machdep.hyperthreading_allowed=1: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot462.png machdep.hyperthreading_allowed=0: top: http://sobomax.sippysoft.com/~sobomax/ScreenShot463.png IMHO, at the very least, if SCHED_ULE doesn't support machdep.hyperthreading_allowed properly, then when that scheduler is selected the sysctl should return ENOTSUP or something like this. -Maxim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 15:50:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B521065670 for ; Mon, 23 Feb 2009 15:50:23 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 88E708FC23 for ; Mon, 23 Feb 2009 15:50:23 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so2045599rvb.43 for ; Mon, 23 Feb 2009 07:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=MzJLb67Yjs+dW8R9gEI1OXK3HYgxuZ7Kr2rW0ya4qGk=; b=OebyrAeehA31YLdVlDNR1eyR8GUCBRQ6pHGelJgoTDqcN/sirgJrlnp17zIT7/l1Z7 lFW8GE22AV7AnLB/UHkEYJitlGPGY+l4H4TQhe1CQxOFgrhlOdGkM1wqiR5rgXlxQrBR iQZLm/Y96tro+sfk6TQ4BQBeIVtJyX85ef1Jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=B8omHhREzgBSdkfeEnwhwTdBLNTTR3FJyOkOEhaXIatI0YbRN3TG74853dxbH0q1dW ihnh+ezjn96uCR4fdiFiosRk0FegnfhYVc7avvhGdGsHL2UikPze2ITIZWOKoeEZYbKY bG4FEdHFykqHUqkjrvnC9E8ox50sZhBRpQHpI= MIME-Version: 1.0 Received: by 10.140.139.3 with SMTP id m3mr2088040rvd.64.1235402477492; Mon, 23 Feb 2009 07:21:17 -0800 (PST) Date: Mon, 23 Feb 2009 16:21:17 +0100 Message-ID: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> From: Christian Walther To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:50:24 -0000 Hi, after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30 (with ZFS root on encrypted geli, works great). Config is: FreeBSD hasking.alashan.nongo 7.1-STABLE FreeBSD 7.1-STABLE #3: Thu Feb 5 21:10:45 CET 2009 root@hasking.alashan.nongo:/usr/obj/usr/src/sys/HASKING i386 I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: Feb 17 20:15:21 hasking kernel: ath0: mem 0xd0210000-0xd021ffff irq 3 at device 0.0 on cardbus0 Feb 17 20:15:21 hasking kernel: ath0: [ITHREAD] Feb 17 20:15:21 hasking kernel: ath0: WARNING: using obsoleted if_watchdog interface Feb 17 20:15:21 hasking kernel: ath0: Ethernet address: 00:19:5b:3a:82:be Feb 17 20:15:21 hasking kernel: ath0: mac 7.9 phy 4.5 radio 5.6 ... Feb 17 21:39:19 hasking kernel: ath0: link state changed to UP Feb 17 21:39:19 hasking kernel: ath0: link state changed to DOWN Feb 17 21:39:23 hasking kernel: ath0: link state changed to UP Feb 17 21:39:23 hasking kernel: ath0: link state changed to DOWN Feb 17 21:39:24 hasking kernel: interrupt storm detected on "irq3:"; throttling interrupt source Next I gave the following card a try: iwi0: mem 0xd0200000-0xd0200fff irq 5 at device 2.0 on pci2 iwi0: Ethernet address: 00:15:00:31:f3:76 iwi0: [ITHREAD] ...and it regularly drops/looses connection to the WLAN router, as stated in the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=124767 Basically, my question is if there is a fix for any of these issues that I haven't found so far, so that I can eventually use one of my existing wireless cards, or if I should switch to a different brand/model. If the latter is the case I'd like to know which one to choose. Regards Christian Walther From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 17:55:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4881D106571D for ; Mon, 23 Feb 2009 17:55:44 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [87.237.210.209]) by mx1.freebsd.org (Postfix) with ESMTP id E1A198FC19 for ; Mon, 23 Feb 2009 17:55:43 +0000 (UTC) (envelope-from peter@pean.org) Received: from pi.pean.org (nl118-171-127.student.uu.se [130.243.171.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter@pean.org) by system.jails.se (Postfix) with ESMTP id BF8A650EDC for ; Mon, 23 Feb 2009 18:40:15 +0100 (CET) Message-Id: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org> From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 18:40:15 +0100 X-Mailer: Apple Mail (2.930.3) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dhclient cant renew lease. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:55:45 -0000 Hi Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or =20= so it cant renew its dhcp-lease. At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to =20 255.255.255.255 port 67 And then it gets an DHCPACK from the gateway. (not 172.21.248.127) But then the machine tries to renew the lease I keep getting messages =20= like this: Feb 23 18:29:06 cone dhclient[1623]: DHCPREQUEST on fxp0 to =20 172.21.248.127 port 67 Feb 23 18:29:06 cone dhclient[1623]: SENDING DIRECT Feb 23 18:29:33 cone dhclient[1623]: DHCPREQUEST on fxp0 to =20 172.21.248.127 port 67 Feb 23 18:29:33 cone dhclient[1623]: SENDING DIRECT until the lease runs out and then the connection drops. I guess 172.21.248.127 is the real dhcp-server. A 'dhclient fxp0' sends a new request to 255.255.255.255 and it =20 immediately fixes the connection. -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 17:57:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D610106566B for ; Mon, 23 Feb 2009 17:57:09 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 454A08FC0A for ; Mon, 23 Feb 2009 17:57:09 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n1NHv4w9031761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Feb 2009 09:57:08 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E12A41CC27; Mon, 23 Feb 2009 09:56:03 -0800 (PST) To: Christian Walther In-reply-to: Your message of "Mon, 23 Feb 2009 16:21:17 +0100." <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> Date: Mon, 23 Feb 2009 09:56:03 -0800 From: "Kevin Oberman" Message-Id: <20090223175603.E12A41CC27@ptavv.es.net> Cc: FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:57:09 -0000 > Date: Mon, 23 Feb 2009 16:21:17 +0100 > From: Christian Walther > Sender: owner-freebsd-stable@freebsd.org > > Hi, > > after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30 > (with ZFS root on encrypted geli, works great). > Config is: > > FreeBSD hasking.alashan.nongo 7.1-STABLE FreeBSD 7.1-STABLE #3: Thu > Feb 5 21:10:45 CET 2009 > root@hasking.alashan.nongo:/usr/obj/usr/src/sys/HASKING i386 > > I tried using my ath based D-Link DWL G650, which still seems to have > some issues in regard to interrupt handling: > > Feb 17 20:15:21 hasking kernel: ath0: mem > 0xd0210000-0xd021ffff irq 3 at device 0.0 on cardbus0 > Feb 17 20:15:21 hasking kernel: ath0: [ITHREAD] > Feb 17 20:15:21 hasking kernel: ath0: WARNING: using obsoleted > if_watchdog interface > Feb 17 20:15:21 hasking kernel: ath0: Ethernet address: 00:19:5b:3a:82:be > Feb 17 20:15:21 hasking kernel: ath0: mac 7.9 phy 4.5 radio 5.6 > ... > Feb 17 21:39:19 hasking kernel: ath0: link state changed to UP > Feb 17 21:39:19 hasking kernel: ath0: link state changed to DOWN > Feb 17 21:39:23 hasking kernel: ath0: link state changed to UP > Feb 17 21:39:23 hasking kernel: ath0: link state changed to DOWN > Feb 17 21:39:24 hasking kernel: interrupt storm detected on "irq3:"; > throttling interrupt source > > > Next I gave the following card a try: > iwi0: mem 0xd0200000-0xd0200fff irq 5 > at device 2.0 on pci2 > iwi0: Ethernet address: 00:15:00:31:f3:76 > iwi0: [ITHREAD] > > ...and it regularly drops/looses connection to the WLAN router, as > stated in the following PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=124767 > > Basically, my question is if there is a fix for any of these issues > that I haven't found so far, so that I can eventually use one of my > existing wireless cards, or if I should switch to a different > brand/model. If the latter is the case I'd like to know which one to > choose. I'm not sure what the problem you are seeing with the Atheros 5212 might be, but I use that wireless card in my T43 and it has worked very well for years. I'm not sure what is using irq3, but it is normally COMM2, which i believe only exists on the T30 when the unit is in a docking station. Could you check on the output of 'vmstat -i' to see what might be using it? Are you running with APIC? I know that it has to be disabled on the T43 and it may need to be on the T30. (It's been a while since I've used the T30.) Add 'hint.apic.0.disabled=1' to /boot/loader to do this. Finally, try 'ifconfig ath0 -bgscan'. Several people have reported that this fixes periodic loss of association on the 5212. By default, background scanning is done every 5 minutes and makes roaming work much better, but seems to have some issues on this card. I'm not at all confident that this will lead to fixing the problem, but it's easy to check on and may point in the right direction. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 18:25:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF281065670 for ; Mon, 23 Feb 2009 18:25:17 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [87.237.210.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8008FC18 for ; Mon, 23 Feb 2009 18:25:17 +0000 (UTC) (envelope-from peter@pean.org) Received: from pi.pean.org (nl118-171-127.student.uu.se [130.243.171.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter@pean.org) by system.jails.se (Postfix) with ESMTP id EB84950B8C; Mon, 23 Feb 2009 19:25:15 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= To: Brooks Davis In-Reply-To: <20090223180839.GA78235@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 19:25:15 +0100 References: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org> <20090223180839.GA78235@lor.one-eyed-alien.net> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-stable@freebsd.org Subject: Re: dhclient cant renew lease. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:25:17 -0000 On Feb 23, 2009, at 7:08 PM, Brooks Davis wrote: > On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote: >> Hi >> Im running FreeBSD 7.0-RELEASE on my gateway and for the last week =20= >> or so it >> cant renew its dhcp-lease. >> >> At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to >> 255.255.255.255 port 67 >> And then it gets an DHCPACK from the gateway. (not 172.21.248.127) >> > > You may be seeing the issue in bin/96018. If so, switching to the =20 > dhclient > from 7.1 should fix it. > > -- Brooks I've been trying with my laptop running 7.1 and it doesnt get any =20 replies from 172.21.248.127. I guess a workaround is to set a shorter rebind-interval.. -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 18:30:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A6F106564A for ; Mon, 23 Feb 2009 18:30:55 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id C98848FC0A for ; Mon, 23 Feb 2009 18:30:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n1NI8dch087694; Mon, 23 Feb 2009 12:08:39 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1NI8dWq087693; Mon, 23 Feb 2009 12:08:39 -0600 (CST) (envelope-from brooks) Date: Mon, 23 Feb 2009 12:08:39 -0600 From: Brooks Davis To: Peter Ankerst?l Message-ID: <20090223180839.GA78235@lor.one-eyed-alien.net> References: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <17C37DBA-E596-41FB-990C-1538800F2766@pean.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 23 Feb 2009 12:08:39 -0600 (CST) Cc: freebsd-stable@freebsd.org Subject: Re: dhclient cant renew lease. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:30:55 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote: > Hi > Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or so = it=20 > cant renew its dhcp-lease. >=20 > At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to=20 > 255.255.255.255 port 67 > And then it gets an DHCPACK from the gateway. (not 172.21.248.127) >=20 > But then the machine tries to renew the lease I keep getting messages lik= e=20 > this: > Feb 23 18:29:06 cone dhclient[1623]: DHCPREQUEST on fxp0 to 172.21.248.12= 7=20 > port 67 > Feb 23 18:29:06 cone dhclient[1623]: SENDING DIRECT > Feb 23 18:29:33 cone dhclient[1623]: DHCPREQUEST on fxp0 to 172.21.248.12= 7=20 > port 67 > Feb 23 18:29:33 cone dhclient[1623]: SENDING DIRECT >=20 > until the lease runs out and then the connection drops. > I guess 172.21.248.127 is the real dhcp-server. >=20 > A 'dhclient fxp0' sends a new request to 255.255.255.255 and it immediate= ly=20 > fixes the connection. You may be seeing the issue in bin/96018. If so, switching to the dhclient =66rom 7.1 should fix it. -- Brooks --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJouYmXY6L6fI4GtQRApulAKDb0iCLDf8t5iBeU3T4rCtMptCVGACgsUHk FZHEDkcLdUVorHW0iViplI0= =7SRZ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 18:39:57 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2061F106575D; Mon, 23 Feb 2009 18:39:57 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D58DF8FC1C; Mon, 23 Feb 2009 18:39:56 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1NIdsQj010051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 10:39:55 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A2ED6A.9040202@FreeBSD.org> Date: Mon, 23 Feb 2009 10:39:38 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:39:59 -0000 Robert Watson wrote: > In the mean time, it sounds like the sysctl does need to be > reimplemented or removed, but one question is how far to take it -- > caches are shared to varying degrees at varying levels of the topology. > However, I believe the recommendation has generally moved to disabling > hyperthreading using the BIOS, as that uses the vendor's notion of > hyperthreading. The idea of changing the setting at run-time is > currently untenable because we don't have the OS infrastructure to take > CPUs out of service, although growing it would be useful in order to > support virtual machine dynamic CPU reconfiguration. Well, as far as I know, what SCHED_4BSD does is simply stopping scheduling threads to the logical core(s). One doesn't need infrastructure to take CPU off-line for doing the same in SCHED_ULE. Unfortunately access to BIOS is not always an option and also some BIOSes don't even provide a feature to turn HTT off. -Maxim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 18:56:31 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5865B1065BCE; Mon, 23 Feb 2009 18:56:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD2F8FC1D; Mon, 23 Feb 2009 18:56:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1F2CD46B23; Mon, 23 Feb 2009 13:56:27 -0500 (EST) Date: Mon, 23 Feb 2009 18:56:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <49A2ED6A.9040202@FreeBSD.org> Message-ID: References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:56:37 -0000 On Mon, 23 Feb 2009, Maxim Sobolev wrote: > Robert Watson wrote: >> In the mean time, it sounds like the sysctl does need to be reimplemented >> or removed, but one question is how far to take it -- caches are shared to >> varying degrees at varying levels of the topology. However, I believe the >> recommendation has generally moved to disabling hyperthreading using the >> BIOS, as that uses the vendor's notion of hyperthreading. The idea of >> changing the setting at run-time is currently untenable because we don't >> have the OS infrastructure to take CPUs out of service, although growing it >> would be useful in order to support virtual machine dynamic CPU >> reconfiguration. > > Well, as far as I know, what SCHED_4BSD does is simply stopping scheduling > threads to the logical core(s). One doesn't need infrastructure to take CPU > off-line for doing the same in SCHED_ULE. > > Unfortunately access to BIOS is not always an option and also some BIOSes > don't even provide a feature to turn HTT off. It's not quite that simple -- in a world of device drivers pinning threads to CPUs for workload distribution, callout threads and sched_bind()/sched_pin() for crypto load distribution, etc, you need a whole infrastructure for software-disabled CPUs. Disabling it using the BIOS or device.hints is the only reliable way to do this right now. Changing the architecture of the kernel to disable CPU cores after boot is a significant investment of work, and as I mentioned elsewhere, it is disable to do this so that we can support dynamic reconfiguration in the presence of a hypervisor, but it's highly non-trivial. There may be some shortcuts that can be taken for policy reasons in the probing of CPUs when the topology is detected that avoid the full dynamic solution having to be done in the short-term, that in effect are a short-hand for device.hints entries, but I don't know to what extent the CPU topology from ACPI is available at the point where we'd need to know that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 18:59:58 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C121D1065D4B; Mon, 23 Feb 2009 18:59:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 95BB58FC1E; Mon, 23 Feb 2009 18:59:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4B44F46B2A; Mon, 23 Feb 2009 13:59:58 -0500 (EST) Date: Mon, 23 Feb 2009 18:59:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: Message-ID: References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:00:00 -0000 On Mon, 23 Feb 2009, Robert Watson wrote: > It's not quite that simple -- in a world of device drivers pinning threads to > CPUs for workload distribution, callout threads and sched_bind()/sched_pin() > for crypto load distribution, etc, you need a whole infrastructure for > software-disabled CPUs. Disabling it using the BIOS or device.hints is the > only reliable way to do this right now. Changing the architecture of the > kernel to disable CPU cores after boot is a significant investment of work, ^^^^ s/disable/desirable/ Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 20:17:47 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433FD1065674; Mon, 23 Feb 2009 20:17:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id DE60F8FC22; Mon, 23 Feb 2009 20:17:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1NKHhhj015083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 12:17:44 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A30456.5010400@FreeBSD.org> Date: Mon, 23 Feb 2009 12:17:26 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:17:48 -0000 Robert Watson wrote: > > On Mon, 23 Feb 2009, Maxim Sobolev wrote: > >> Robert Watson wrote: >>> In the mean time, it sounds like the sysctl does need to be >>> reimplemented or removed, but one question is how far to take it -- >>> caches are shared to varying degrees at varying levels of the >>> topology. However, I believe the recommendation has generally moved >>> to disabling hyperthreading using the BIOS, as that uses the vendor's >>> notion of hyperthreading. The idea of changing the setting at >>> run-time is currently untenable because we don't have the OS >>> infrastructure to take CPUs out of service, although growing it would >>> be useful in order to support virtual machine dynamic CPU >>> reconfiguration. >> >> Well, as far as I know, what SCHED_4BSD does is simply stopping >> scheduling threads to the logical core(s). One doesn't need >> infrastructure to take CPU off-line for doing the same in SCHED_ULE. >> >> Unfortunately access to BIOS is not always an option and also some >> BIOSes don't even provide a feature to turn HTT off. > > It's not quite that simple -- in a world of device drivers pinning > threads to CPUs for workload distribution, callout threads and > sched_bind()/sched_pin() for crypto load distribution, etc, you need a > whole infrastructure for software-disabled CPUs. Disabling it using the > BIOS or device.hints is the only reliable way to do this right now. > Changing the architecture of the kernel to disable CPU cores after boot > is a significant investment of work, and as I mentioned elsewhere, it is > disable to do this so that we can support dynamic reconfiguration in the > presence of a hypervisor, but it's highly non-trivial. There may be > some shortcuts that can be taken for policy reasons in the probing of > CPUs when the topology is detected that avoid the full dynamic solution > having to be done in the short-term, that in effect are a short-hand for > device.hints entries, but I don't know to what extent the CPU topology > from ACPI is available at the point where we'd need to know that. So, are you suggesting that we should disable machdep.hyperthreading_allowed with ULE in 7.x and current to avoid confusion? -Maxim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 20:27:05 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD3F10656CC; Mon, 23 Feb 2009 20:27:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 829B88FC1F; Mon, 23 Feb 2009 20:27:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 36ADC46B2A; Mon, 23 Feb 2009 15:27:05 -0500 (EST) Date: Mon, 23 Feb 2009 20:27:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <49A30456.5010400@FreeBSD.org> Message-ID: References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> <49A30456.5010400@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:27:06 -0000 On Mon, 23 Feb 2009, Maxim Sobolev wrote: >>> Unfortunately access to BIOS is not always an option and also some BIOSes >>> don't even provide a feature to turn HTT off. >> >> It's not quite that simple -- in a world of device drivers pinning threads >> to CPUs for workload distribution, callout threads and >> sched_bind()/sched_pin() for crypto load distribution, etc, you need a >> whole infrastructure for software-disabled CPUs. Disabling it using the >> BIOS or device.hints is the only reliable way to do this right now. >> Changing the architecture of the kernel to disable CPU cores after boot is >> a significant investment of work, and as I mentioned elsewhere, it is >> disable to do this so that we can support dynamic reconfiguration in the >> presence of a hypervisor, but it's highly non-trivial. There may be some >> shortcuts that can be taken for policy reasons in the probing of CPUs when >> the topology is detected that avoid the full dynamic solution having to be >> done in the short-term, that in effect are a short-hand for device.hints >> entries, but I don't know to what extent the CPU topology from ACPI is >> available at the point where we'd need to know that. > > So, are you suggesting that we should disable machdep.hyperthreading_allowed > with ULE in 7.x and current to avoid confusion? Possibly even without ULE. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 21:13:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4731065689 for ; Mon, 23 Feb 2009 21:13:36 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 774758FC1F for ; Mon, 23 Feb 2009 21:13:36 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so789128yxl.13 for ; Mon, 23 Feb 2009 13:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SFYuYVZpuqvfQUaFk5eh0GE6fQylTwT5afc6BW4xhh4=; b=BvVkPEGlO1sx1jIWY01ftmU2F56msVcV//68uzSuMIy9Kp/0NvHWprLZ20Bu0SBQVJ /Zfu1CHSBcHsfCZ307687r3ApGVZypdWFCYLimytY2Sklnza4wB+0vtEOZeHnNHWOo/m yMQq3zOqJJ86kZSVXkJQG/72oKBEmfHisfeRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZkCiG9LXcEmX/3WAgomK3DkaVxsGAMJpRgaVfeJIo79xTKx/FdibcOQrEF07xxMWPR p7g4W8ajJ+qq9/Yw56x+c0AIxjjgboOhlIlobWKOI1VzLDgg/GWavFp7VqnLp2Oje2d9 /7/wc/3Ns8m6RvmXbGSpGY0q5Te3t+E4NRRBA= MIME-Version: 1.0 Received: by 10.231.19.204 with SMTP id c12mr6659813ibb.39.1235423614841; Mon, 23 Feb 2009 13:13:34 -0800 (PST) In-Reply-To: <20090223175603.E12A41CC27@ptavv.es.net> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <20090223175603.E12A41CC27@ptavv.es.net> Date: Mon, 23 Feb 2009 22:13:34 +0100 Message-ID: <14989d6e0902231313q10b20839g724b0f1939c24aac@mail.gmail.com> From: Christian Walther To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:13:37 -0000 Hi Kevin, lets say it this way: Right now the DWL-G650 works. I'm not sure why, but I did reset the BIOS configurations to its default and started manually configuration some of the used interrupts. This is why the snippets of the logfiles I sent in my previous mail don't match the current configuration. Currently, the card uses irq 5 as supplied by cbb0. The last messages I received concerning the issue were: Feb 23 19:43:52 hasking kernel: interrupt storm detected on "irq5:"; throttling interrupt source Feb 23 19:43:53 hasking kernel: interrupt storm detected on "irq5:"; throttling interrupt source Feb 23 19:43:54 hasking kernel: ath0: link state changed to UP Feb 23 19:43:54 hasking kernel: ath0: link state changed to DOWN Feb 23 19:43:58 hasking kernel: ath0: link state changed to UP Feb 23 19:43:58 hasking kernel: ath0: link state changed to DOWN Feb 23 19:44:03 hasking kernel: ath0: link state changed to UP Feb 23 19:44:03 hasking kernel: ath0: link state changed to DOWN Feb 23 19:44:05 hasking kernel: interrupt storm detected on "irq5:"; throttling interrupt source Feb 23 19:44:05 hasking kernel: ath0: link state changed to UP Feb 23 19:44:05 hasking kernel: ath0: link state changed to DOWN Feb 23 19:44:09 hasking kernel: ath0: rx FIFO overrun; resetting Feb 23 19:44:20 hasking kernel: ath0: link state changed to UP This has actually been the last time that I've seen those errors. I even transferred a PCBSD DVD iso image to my server using FTP. I guess I made two mistakes during my entire testing phase: 1. I wrongly assumed that the issue with the ath card was the same as the one I experienced some time ago, including some HAL issue locking the card, interrupt storms during usage and crashes on removal of the card. 2. After I did the BIOS reset I obviously just tested my iwi card. While there are still some interrupt storm related messages, they seem to appear during boot (HW init) only. Kevin, thank you for your input, which made me review the issue again. The only problem that remains is that my machine crashes when I remove the card. I'll review this later. Thanks again for your help, I'm happy that I can use this card as expected, and that I don't need to get another one. Regards Christian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 05:58:02 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9878C106564A; Tue, 24 Feb 2009 05:58:02 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 6576C8FC13; Tue, 24 Feb 2009 05:58:02 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1O5vwLj049290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 21:57:59 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A38C54.7070601@FreeBSD.org> Date: Mon, 23 Feb 2009 21:57:40 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> <49A30456.5010400@FreeBSD.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080303000001020500010202" Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 05:58:03 -0000 This is a multi-part message in MIME format. --------------080303000001020500010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: >> So, are you suggesting that we should disable >> machdep.hyperthreading_allowed with ULE in 7.x and current to avoid >> confusion? > > Possibly even without ULE. I've verified - the tunable/sysctl works just fine with SCHED_4BSD in 7.1, so that I am not sure it's worth ripping it off. Instead, I've re-implemented the feature differently - by disabling HT cores at detection time when SCHED_ULE is compiled in and machdep.hyperthreading_allowed is set to 0 in loader.conf. Patch for 7.1 is attached. Apart from the fact that it's not possible to change the setting at run-time, this version should be even better by not starting up HT cores in the first place. I would appreciate if somebody familiar with the code in question can review the patch, particularly part that moves assign_cpu_ids() and start_all_aps() calls little bit further in the cpu_mp_start(). I need them there so that I can use hyperthreading_cpus in assign_cpu_ids(). Thanks in advance. -Maxim --------------080303000001020500010202 Content-Type: text/plain; name="machdep.hyperthreading_allowed.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="machdep.hyperthreading_allowed.diff" --- i386/i386/mp_machdep.c 2009-01-19 07:34:49.000000000 -0800 +++ /tmp/mp_machdep.c 2009-02-23 21:38:18.000000000 -0800 @@ -209,6 +210,7 @@ int cpu_present:1; int cpu_bsp:1; int cpu_disabled:1; + int cpu_hyperthread:1; } static cpu_info[MAX_APIC_ID + 1]; int cpu_apic_ids[MAXCPU]; @@ -405,11 +407,6 @@ ("BSP's APIC ID doesn't match boot_cpu_id")); cpu_apic_ids[0] = boot_cpu_id; - assign_cpu_ids(); - - /* Start each Application Processor */ - start_all_aps(); - /* Setup the initial logical CPUs info. */ logical_cpus = logical_cpus_mask = 0; if (cpu_feature & CPUID_HTT) @@ -457,6 +454,11 @@ hyperthreading_cpus = logical_cpus; } + assign_cpu_ids(); + + /* Start each Application Processor */ + start_all_aps(); + set_interrupt_apic_ids(); /* Last, setup the cpu topology now that we have probed CPUs */ @@ -471,18 +473,26 @@ cpu_mp_announce(void) { int i, x; + const char *hyperthread; /* List CPUs */ printf(" cpu0 (BSP): APIC ID: %2d\n", boot_cpu_id); for (i = 1, x = 0; x <= MAX_APIC_ID; x++) { if (!cpu_info[x].cpu_present || cpu_info[x].cpu_bsp) continue; + if (cpu_info[x].cpu_hyperthread) { + hyperthread = "/HT"; + } else { + hyperthread = ""; + } if (cpu_info[x].cpu_disabled) - printf(" cpu (AP): APIC ID: %2d (disabled)\n", x); + printf(" cpu (AP%s): APIC ID: %2d (disabled)\n", + hyperthread, x); else { KASSERT(i < mp_ncpus, ("mp_ncpus and actual cpus are out of whack")); - printf(" cpu%d (AP): APIC ID: %2d\n", i++, x); + printf(" cpu%d (AP%s): APIC ID: %2d\n", i++, + hyperthread, x); } } } @@ -691,11 +701,24 @@ { u_int i; + TUNABLE_INT_FETCH("machdep.hyperthreading_allowed", + &hyperthreading_allowed); + /* Check for explicitly disabled CPUs. */ for (i = 0; i <= MAX_APIC_ID; i++) { if (!cpu_info[i].cpu_present || cpu_info[i].cpu_bsp) continue; + if (hyperthreading_cpus > 1 && i % hyperthreading_cpus != 0) { + cpu_info[i].cpu_hyperthread = 1; +#if defined(SCHED_ULE) + if (hyperthreading_allowed == 0) { + cpu_info[i].cpu_disabled = 1; + continue; + } +#endif + } + /* Don't use this CPU if it has been disabled by a tunable. */ if (resource_disabled("lapic", i)) { cpu_info[i].cpu_disabled = 1; @@ -1410,6 +1433,12 @@ if (error || !req->newptr) return (error); +#ifdef SCHED_ULE + if (allowed != hyperthreading_allowed) + return (ENOTSUP); + return (error); +#endif + if (allowed) hlt_cpus_mask &= ~hyperthreading_cpus_mask; else @@ -1454,8 +1483,6 @@ * of hlt_logical_cpus. */ if (hyperthreading_cpus_mask) { - TUNABLE_INT_FETCH("machdep.hyperthreading_allowed", - &hyperthreading_allowed); SYSCTL_ADD_PROC(&logical_cpu_clist, SYSCTL_STATIC_CHILDREN(_machdep), OID_AUTO, "hyperthreading_allowed", CTLTYPE_INT|CTLFLAG_RW, --------------080303000001020500010202-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 06:21:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40CDC1065670 for ; Tue, 24 Feb 2009 06:21:04 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 10C018FC17 for ; Tue, 24 Feb 2009 06:21:03 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LbqNX-0004pT-T1 for freebsd-stable@freebsd.org; Mon, 23 Feb 2009 22:02:51 -0800 Message-ID: <22176398.post@talk.nabble.com> Date: Mon, 23 Feb 2009 22:02:51 -0800 (PST) From: aneeth To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ahmed.aneeth@gmail.com References: <20090119132504.GA6853@dchagin.dialup.corbina.ru> Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:21:04 -0000 Pete French-2 wrote: > >> Probably it is your case, try please. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=130652&cat= > > OK, will give this a try, unless anyone else wants any traces from > this locked machine ? Is there a known way to tickle this bug > when I've rebooted, to make sure it's fixed ? > > thanks, > > -pete. > _______________________________________________ > 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" > > We'v been having similar issues with a couple of our servers as well (7.0 and 7.1). However the problem shows up only on quad core machines. The dual core machines r running fine. -- View this message in context: http://www.nabble.com/Big-problems-with-7.1-locking-up-%3A-%28-tp21364913p22176398.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 06:25:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FE2106566C for ; Tue, 24 Feb 2009 06:25:11 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id E613D8FC08 for ; Tue, 24 Feb 2009 06:25:10 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n1O6Bj3a040936 for ; Mon, 23 Feb 2009 23:11:45 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n1O6Bjbw040933 for ; Mon, 23 Feb 2009 23:11:45 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 23 Feb 2009 23:11:45 -0700 (MST) From: Warren Block To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (wonkity.com [127.0.0.1]); Mon, 23 Feb 2009 23:11:45 -0700 (MST) Subject: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:25:11 -0000 Lately I've installed a couple of test systems from 7.1-RELEASE CDs, then csupped to RELENG_7 from cvsup9: *default host=cvsup9.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_7 *default delete use-rel-suffix mergemaster adds a *lot* of old files in /etc that were not there in 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a bunch of bluetooth files and /etc/isdn/*. The version numbers and dates in mergemaster look wrong. For example, /etc/bluetooth/hcsecd.conf: # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax Exp $ Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? The latest entries for files in /etc/isdn are 9 months old, and were removals. This looks like an error, but maybe I'm missing something. And other cvsup mirrors seem to agree with cvsup9. -Warren Block * Rapid City, South Dakota USA From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 08:58:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E41065670 for ; Tue, 24 Feb 2009 08:58:33 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from smtp.owt.com (smtp.owt.com [66.119.213.2]) by mx1.freebsd.org (Postfix) with ESMTP id 033908FC1D for ; Tue, 24 Feb 2009 08:58:32 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from kstewart2.owt.com (kstewart2.owt.com [64.146.237.228]) (authenticated bits=0) by smtp.owt.com (8.13.8/8.13.8) with ESMTP id n1O8wVoZ001345; Tue, 24 Feb 2009 00:58:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=owt.com; s=default; t=1235465912; bh=5xZ3U3T37ImJ4w328EbKIjpijpo+tp4jy5Gn307EOKk=; h=From:To:Subject:Date:Cc:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=Dy/VoptQFCrnC ID+Go64WGLjVV0j0bGKfJB8vTxaOWnP+hYcSekTN0NLzuadTb48DpEWt+zYC27/Gx+G kGzF8tSSRqw70PX6J15+n7roDS2/LjgvCog8HUbrrp8bT0S+EinA68k1GbchhPI7PsJ os5+A3lcxdBOLKKPzRfabXQU= From: Kent Stewart To: freebsd-stable@freebsd.org Date: Tue, 24 Feb 2009 00:58:31 -0800 User-Agent: KMail/1.9.10 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: <200902240058.31212.kstewart@owt.com> Cc: Warren Block Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:58:33 -0000 On Monday 23 February 2009 10:11:45 pm Warren Block wrote: > Lately I've installed a couple of test systems from 7.1-RELEASE CDs, > then csupped to RELENG_7 from cvsup9: > > *default host=cvsup9.FreeBSD.org > *default base=/var/db > *default prefix=/usr > *default release=cvs tag=RELENG_7 > *default delete use-rel-suffix > > mergemaster adds a *lot* of old files in /etc that were not there in > 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a > bunch of bluetooth files and /etc/isdn/*. > > The version numbers and dates in mergemaster look wrong. For example, > /etc/bluetooth/hcsecd.conf: > > # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ > # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax > Exp $ > > Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? > > The latest entries for files in /etc/isdn are 9 months old, and were > removals. > > This looks like an error, but maybe I'm missing something. And other > cvsup mirrors seem to agree with cvsup9. You are looking at the version for the 7.1 release version. The RELENG_7 version is Revision 1.3: download - view: text, markup, annotated - select for diffs Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0, RELENG_7, HEAD Branch point for: RELENG_7_1 Diff to: previous 1.2: preferred, colored Changes since revision 1.2: +1 -1 lines Go to http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/bluetooth/hcsecd.conf and you can see the versions and the tags. Kent -- kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 10:33:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D16106566C for ; Tue, 24 Feb 2009 10:33:44 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2D98FC23 for ; Tue, 24 Feb 2009 10:33:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (ppp121-45-204-111.lns10.adl2.internode.on.net [121.45.204.111]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1OAXawA087333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 21:03:41 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 24 Feb 2009 19:56:30 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2080303.D1j3bpGAEV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902241956.46306.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: E7400 Speedstep support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 10:33:45 -0000 --nextPart2080303.D1j3bpGAEV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I recently got a new Intel E7400 based system and dmesg reports.. est0: on cpu0 est0: Guessed bus clock (high) of 37 MHz est0: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Guessed bus clock (high) of 37 MHz est1: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est1 attach returned 6 p4tcc1: on cpu1 I'm running 7.1-STABLE and I was wondering how hard it is to add support fo= r=20 est for this CPU? Thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2080303.D1j3bpGAEV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJo71H5ZPcIHs/zowRAtceAJ0fuY8GP76q7Ohxj4fDy34HyftONgCgme14 xpjKemIJZI/qDXnvcyEXy9c= =J1l1 -----END PGP SIGNATURE----- --nextPart2080303.D1j3bpGAEV-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 10:35:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D46D106568D for ; Tue, 24 Feb 2009 10:35:15 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 82AE68FC3C for ; Tue, 24 Feb 2009 10:35:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (ppp121-45-204-111.lns10.adl2.internode.on.net [121.45.204.111]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1OAZCk1087458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 21:05:12 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 24 Feb 2009 21:05:04 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200902231200.38164.doconnor@gsoft.com.au> In-Reply-To: <200902231200.38164.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2206591.Qr5RbBWDNr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902242105.05667.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: Re: Intel Q45 problems on 7.1-STABLE (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 10:35:16 -0000 --nextPart2206591.Qr5RbBWDNr Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote: > Initially it hung solid when X started, however when I reduced the amount > of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text > console and back to X then the machine locks solid (no numlock, have to > hard reset). > > I note that dmesg reports 32764k of stolen memory, however I set the DVMT > RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size is > always reported as 256Mb no matter what it actually is in the BIOS. Someone in a private email suggested I update the BIOS (went from 63 to 73)= =20 and it seems to work fine now. The reported value of stolen memory is still wrong however. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2206591.Qr5RbBWDNr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJo81Z5ZPcIHs/zowRAnHAAJ9bJXG8VhihgDM8ZLx+Co2y+YJVEwCgiipm u472womlyzmrgfYUzi9f3XM= =p8a9 -----END PGP SIGNATURE----- --nextPart2206591.Qr5RbBWDNr-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 14:06:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354BA106564A for ; Tue, 24 Feb 2009 14:06:40 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5AC8FC0A for ; Tue, 24 Feb 2009 14:06:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 388E72A3C6E for ; Tue, 24 Feb 2009 09:06:39 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 24 Feb 2009 09:06:39 -0500 X-Sasl-enc: AsM4SdXZ92joHGz3b8WdxwM6VEPdxOkvZUM+5trPckFU 1235484392 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 327B526A13 for ; Tue, 24 Feb 2009 09:06:32 -0500 (EST) Message-ID: <49A3FEE6.7030606@incunabulum.net> Date: Tue, 24 Feb 2009 14:06:30 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Cleaning unused libraries and rebuilding dependent ones? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:06:40 -0000 Hi all, I'm sure that these questions have been asked before, however, a quick search of forums on the Web didn't turn up any obvious answers. I currently use portupgrade on all my FreeBSD installations, however, I have noticed over time that a fair amount of detritus can build up in ${PREFIX}/lib/compat/pkg. So my questions are:- 1. Is there a tool like Gentoo's revdep-rebuild to force packages depending on packaged libraries to be rebuilt? 2. Is there a more complete tool to clean orphaned libraries like 'portsclean -L' used to do? Whilst I greatly appreciate the hard work and effort which the FreeBSD ports maintainers put in to ensure shared library versions get bumped when needed, this isn't always possible, as it requires keeping a sharp eye out for 3rd party software packages which do the wrong thing, and don't bump the major(s) when significant semantic changes happen inside their libraries, or when the ABI changes. [1] revdep-rebuild has very similar semantics to what I'm looking for, as it will navigate the dependency graph for all packages installed on the system, and rebuild packages where dependent libraries have changed. To do the same with portupgrade alone, I need to know which port(s) contain shared libraries, and tell it to go off and rebuild these *specific* packages if things change. [2] 'portsclean -L' used to do something :-) it does not appear to do anything now. I realize I could use libchk to discover which libraries are unreferenced at load-time, however, a fair number of the libraries which portupgrade moves into ${PREFIX}/lib/compat/pkg can potentially be loaded by dlopen() at run-time. Using libchk's output to remove unreferenced libraries isn't really an option without significant post-processing of its output. I would rather not rely on 'portupgrade -f -a -r', as this is going to cause a *lot* of work on the affected systems. Thanks for any help! BMS From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 16:28:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6C31065686 for ; Tue, 24 Feb 2009 16:28:16 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id AA5038FC16 for ; Tue, 24 Feb 2009 16:28:16 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by gxk24 with SMTP id 24so8886407gxk.19 for ; Tue, 24 Feb 2009 08:28:16 -0800 (PST) Received: by 10.231.15.130 with SMTP id k2mr44115iba.31.1235492895763; Tue, 24 Feb 2009 08:28:15 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id s30sm7643841qbs.20.2009.02.24.08.28.14 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 08:28:14 -0800 (PST) From: "SDH Support" To: "'FreeBSD'" References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> In-Reply-To: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> Date: Tue, 24 Feb 2009 11:28:10 -0500 Message-ID: <003601c9969c$e2cdc310$a8694930$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmVzoVcywCbNcL5RXKKSiN7SlX9TgAziePQ Content-Language: en-us Subject: RE: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@stardothosting.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:28:17 -0000 > I tried using my ath based D-Link DWL G650, which still seems to have > some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. --- Kevin www.stardothosting.com/linux-vps-hosting From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 17:05:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3E1106566C for ; Tue, 24 Feb 2009 17:05:32 +0000 (UTC) (envelope-from kutulu@kutulu.org) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAE48FC12 for ; Tue, 24 Feb 2009 17:05:32 +0000 (UTC) (envelope-from kutulu@kutulu.org) Received: from basement.kutulu.org ([70.121.200.185]) by cdptpa-omta02.mail.rr.com with ESMTP id <20090224164440.CDIP18810.cdptpa-omta02.mail.rr.com@basement.kutulu.org>; Tue, 24 Feb 2009 16:44:40 +0000 Received: by basement.kutulu.org (Postfix, from userid 58) id 96EF811495; Tue, 24 Feb 2009 11:44:39 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on basement.kutulu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from [127.0.0.1] (localhost [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTPS id 7D27A1146C; Tue, 24 Feb 2009 11:44:37 -0500 (EST) Message-ID: <49A423F1.8050700@kutulu.org> Date: Tue, 24 Feb 2009 11:44:33 -0500 From: Mike Edenfield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: Bruce Simpson References: <49A3FEE6.7030606@incunabulum.net> In-Reply-To: <49A3FEE6.7030606@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Cleaning unused libraries and rebuilding dependent ones? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:05:32 -0000 On 2/24/2009 9:06 AM, Bruce Simpson wrote: > Hi all, > [1] revdep-rebuild has very similar semantics to what I'm looking for, > as it will navigate the dependency graph for all packages installed on > the system, and rebuild packages where dependent libraries have changed. > To do the same with portupgrade alone, I need to know which port(s) > contain shared libraries, and tell it to go off and rebuild these > *specific* packages if things change. I don't think revdep-rebuild works as cleanly as you think. Technically, revdep-rebuild only locates packages that are *already broken* due to missing shared libraries, and rebuilds them. What revdep-rebuild does is literally run ldd on every executable file in the search path, grep for either "not found" or a specific library name, then assign each broken binary to a package name for portage to rebuild. This is exactly what libchk also does, so the effect would be the same. Specifically, revdep-rebuild also won't pick up missing dlopen() libs and such. The semantics you're talking about sounds like the new @preserved-libs set that's in the upcoming portage, but in order for that to work it has to be maintained at the time of library update: as a shared lib is moved into the compat folder, record any packages that depend on the previously installed package into a set for later rebuilding. --K From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 19:10:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3AB10656CA for ; Tue, 24 Feb 2009 19:10:17 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6034E8FC08 for ; Tue, 24 Feb 2009 19:10:17 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.2] (adsl-156-5-199.bna.bellsouth.net [70.156.5.199]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n1OJ8tNd005498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 14:08:55 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Daniel O'Connor" In-Reply-To: <200902242105.05667.doconnor@gsoft.com.au> References: <200902231200.38164.doconnor@gsoft.com.au> <200902242105.05667.doconnor@gsoft.com.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-wXMlR5orbmVi9kzXB/4z" Organization: FreeBSD Date: Tue, 24 Feb 2009 13:10:09 -0600 Message-Id: <1235502609.1273.27.camel@widget.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Intel Q45 problems on 7.1-STABLE (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:10:18 -0000 --=-wXMlR5orbmVi9kzXB/4z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-02-24 at 21:05 +1030, Daniel O'Connor wrote: > On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote: > > Initially it hung solid when X started, however when I reduced the amou= nt > > of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the tex= t > > console and back to X then the machine locks solid (no numlock, have to > > hard reset). > > > > I note that dmesg reports 32764k of stolen memory, however I set the DV= MT > > RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size i= s > > always reported as 256Mb no matter what it actually is in the BIOS. >=20 > Someone in a private email suggested I update the BIOS (went from 63 to 7= 3)=20 > and it seems to work fine now. >=20 > The reported value of stolen memory is still wrong however. Hrm, I wonder if I have missed an MFC... Please send me some logs and additional details. Your -STABLE is current right? robert. --=20 Robert Noland FreeBSD --=-wXMlR5orbmVi9kzXB/4z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmkRhEACgkQM4TrQ4qfRONsCgCdEByOQQKtJ3mUzWelliZSK+WS 06wAn0qjs98JigpM2T5Ec5HFxiFUzNDC =gDXw -----END PGP SIGNATURE----- --=-wXMlR5orbmVi9kzXB/4z-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 20:13:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4EB2106566C for ; Tue, 24 Feb 2009 20:13:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 730188FC14 for ; Tue, 24 Feb 2009 20:13:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so129923fgb.35 for ; Tue, 24 Feb 2009 12:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RBDxYr5jIsVYDfwIdzrABRFQsZpHNb9mXt/ZkVurFyM=; b=u3e0DKFnMAT53IQDRMTUD2uhNLjQM8vrxK8MOxBxceWSbyj9N9bcmp93ujhi3C9Mh0 CXFEgaj59sTlLTBYbmvH69WyzODK/Y7p2tyuClnhLFWGwPH3itnpkLZNZ+tfUtpDjnHu +Rx1LJrIG7+Uf/HsYqiNicfZSLfORlKHnhNZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AYBX50y4j4btJKWJTefZDUmVHQD7C90NzEa0o5t8VOEaeK7+lJn2CCp/F+Qa/2olc5 U6R/HlEITPlH4lUzc6SwpLib41zKnPmW3ipupkZ0a3L3JHPhA/p+eJ1bWC3HHoEnTX8g 6fZ18G3So+9dFv0dAuj57qHMO/nFwgEiOzRTM= MIME-Version: 1.0 Received: by 10.86.29.8 with SMTP id c8mr96444fgc.67.1235506413453; Tue, 24 Feb 2009 12:13:33 -0800 (PST) In-Reply-To: <200902241956.46306.doconnor@gsoft.com.au> References: <200902241956.46306.doconnor@gsoft.com.au> Date: Tue, 24 Feb 2009 23:13:33 +0300 Message-ID: From: pluknet To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: E7400 Speedstep support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:13:35 -0000 2009/2/24 Daniel O'Connor : > Hi, > I recently got a new Intel E7400 based system and dmesg reports.. > est0: on cpu0 > est0: Guessed bus clock (high) of 37 MHz > est0: Guessed bus clock (low) of 466 MHz > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6164a2206004a22 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est1: Guessed bus clock (high) of 37 MHz > est1: Guessed bus clock (low) of 466 MHz > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6164a2206004a22 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > > I'm running 7.1-STABLE and I was wondering how hard it is to add support for > est for this CPU? > May those error messages be BIOS related? >From my E7200 (well, this is from -current): cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - CF, should be C6 [20070320] est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 dev.cpu has also expected values. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 21:31:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A62B1065672 for ; Tue, 24 Feb 2009 21:31:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 420F28FC17 for ; Tue, 24 Feb 2009 21:31:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D5FC846B23; Tue, 24 Feb 2009 16:31:09 -0500 (EST) Date: Tue, 24 Feb 2009 21:31:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: aneeth In-Reply-To: <22176398.post@talk.nabble.com> Message-ID: References: <20090119132504.GA6853@dchagin.dialup.corbina.ru> <22176398.post@talk.nabble.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:31:11 -0000 On Mon, 23 Feb 2009, aneeth wrote: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130652&cat= >> >> OK, will give this a try, unless anyone else wants any traces from this >> locked machine ? Is there a known way to tickle this bug when I've >> rebooted, to make sure it's fixed ? > > We'v been having similar issues with a couple of our servers as well (7.0 > and 7.1). However the problem shows up only on quad core machines. The dual > core machines r running fine. FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) The patches I sent him are at: http://www.watson.org/~robert/freebsd/20090221-route-locking.diff They do not include the patch from the above PR which I want to handle separately as it's a significantly different issue. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 21:46:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7AA710656C3 for ; Tue, 24 Feb 2009 21:46:35 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id A6FF08FC2E for ; Tue, 24 Feb 2009 21:46:35 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1OLkYg5073699 for ; Tue, 24 Feb 2009 15:46:34 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1OLkWP1057877 for ; Tue, 24 Feb 2009 15:46:32 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49A46AB4.3080003@palisadesys.com> Date: Tue, 24 Feb 2009 15:46:28 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Tue, 24 Feb 2009 15:46:32 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_48 0.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:46:43 -0000 I think I may have found a clue regarding some of the hangs I'm seeing on FreeBSD 7.1. I have a program (kvoop), compiled under FreeBSD 6 and using compatibility libraries under FreeBSD 7, that seems to be consistently involved during these hangs. This time, I noticed that many processes are stopped, waiting on the ufs lock. I can't tell for certain, but I assume this kvoop process 33203 is blocking the other processes. The kvoop process looks to me like it is waiting for a mutex, but nothing shows up being deadlocked. Am I on the right track? Is there something else I should be looking for? (kgdb) proc 33203 [Switching to thread 129 (Thread 100241)]#0 sched_switch ( td=0xffffff0019109a50, newtd=0x0, flags=1) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) where #0 sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1) at ../../../kern/sched_ule.c:1944 #1 0xffffffff803a573b in mi_switch (flags=1, newtd=0x0) at ../../../kern/kern_synch.c:440 #2 0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available. ) at ../../../kern/subr_turnstile.c:748 #3 0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220, tid=18446742974618442320, opts=Variable "opts" is not available. ) at ../../../kern/kern_mutex.c:420 #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) at ../../../kern/kern_mutex.c:186 #5 0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8, vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40) at ../../../kern/vfs_cache.c:327 #6 0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at ../../../kern/vfs_cache.c:674 #7 0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440, a=0xffffffffa2d936b0) at vnode_if.c:99 #8 0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57 #9 0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0) at ../../../kern/vfs_lookup.c:219 #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0, flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600, fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188 #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50, path=0xffffac30
, pathseg=Variable "pathseg" is not available. ) at ../../../kern/vfs_syscalls.c:1032 #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80) at ../../../amd64/ia32/ia32_syscall.c:182 #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65 #14 0x0000000028284037 in ?? () (kgdb) frame 4 #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) at ../../../kern/kern_mutex.c:186 186 _get_sleep_lock(m, curthread, opts, file, line); (kgdb) list 181 ("mtx_lock() of spin mutex %s @ %s:%d", m->lock_object.lo_name, 182 file, line)); 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER | LOP_EXCLUSIVE, 184 file, line); 185 186 _get_sleep_lock(m, curthread, opts, file, line); 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, m->mtx_recurse, file, 188 line); 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, file, line); 190 curthread->td_locks++; (kgdb) print *m $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache", lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600}, lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0} From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 22:47:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7413106567B for ; Tue, 24 Feb 2009 22:47:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 846958FC0A for ; Tue, 24 Feb 2009 22:47:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KFL003J1DZW8L60@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 24 Feb 2009 23:47:56 +0100 (CET) Received: from kg-work2.kg4.no ([80.203.109.110]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KFL00AJZDZWSVA0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 24 Feb 2009 23:47:56 +0100 (CET) Date: Tue, 24 Feb 2009 23:47:56 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no> In-reply-to: <200902240058.31212.kstewart@owt.com> References: <200902240058.31212.kstewart@owt.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:47:59 -0000 On Tue, 24 Feb 2009 00:58:31 -0800 Kent Stewart wrote: > You are looking at the version for the 7.1 release version. The > RELENG_7 version is The real question is: why are the files in 7.1-release newer than those in RELENG_7? In other words: why haven't those files been updated in RELENG_7? Are there something wrong with the newer files? For RELENG_7 users it is inconvenient to have to go through all these files every time a 7.1-release install gets updated to RELENG_7. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 22:53:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB65F1065679 for ; Tue, 24 Feb 2009 22:53:19 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7543F8FC1F for ; Tue, 24 Feb 2009 22:53:19 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n1OMrIkL045034; Tue, 24 Feb 2009 15:53:18 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n1OMrI0R045031; Tue, 24 Feb 2009 15:53:18 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 24 Feb 2009 15:53:18 -0700 (MST) From: Warren Block To: Kent Stewart In-Reply-To: <200902240058.31212.kstewart@owt.com> Message-ID: References: <200902240058.31212.kstewart@owt.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (wonkity.com [127.0.0.1]); Tue, 24 Feb 2009 15:53:18 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:53:20 -0000 On Tue, 24 Feb 2009, Kent Stewart wrote: > On Monday 23 February 2009 10:11:45 pm Warren Block wrote: >> Lately I've installed a couple of test systems from 7.1-RELEASE CDs, >> then csupped to RELENG_7 from cvsup9: >> >> mergemaster adds a *lot* of old files in /etc that were not there in >> 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a >> bunch of bluetooth files and /etc/isdn/*. >> >> The version numbers and dates in mergemaster look wrong. For example, >> /etc/bluetooth/hcsecd.conf: >> >> # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ >> # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax >> Exp $ >> >> Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? > > You are looking at the version for the 7.1 release version. The RELENG_7 > version is > > Revision 1.3: download - view: text, markup, annotated - select for diffs > Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax > Branches: MAIN > CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, > RELENG_7_0, RELENG_7, HEAD > Branch point for: RELENG_7_1 > Diff to: previous 1.2: preferred, colored > Changes since revision 1.2: +1 -1 lines I guess I just don't understand. Why did that file and so many others in /etc go backwards: 7.1-RELEASE had 1.3.6.1 2008/11/25 Three months later: RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 Were those later versions (maybe just version strings) included in 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change is just fixing that error? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 23:23:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B0C1106568F for ; Tue, 24 Feb 2009 23:23:28 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1E26F8FC1B for ; Tue, 24 Feb 2009 23:23:28 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by wf-out-1314.google.com with SMTP id 27so2850783wfd.7 for ; Tue, 24 Feb 2009 15:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fuaJDVfgBQD91IAEZn6S0T1oitBF+GKQAbqapOm/LGg=; b=MZU6x2Ae7Y7ORDC6h+5WFcr2S6417Jjnq+lOdL4KTDuU6ZeqVlqGeqaHsPSnwvu35m vYwUQ5gTh2gPwdsfAE9KynswLHDqiEH4yOtBbsHpxzfPHfHDMwadYMeBm2Q6N8JILgbm sMCa8+N8LSWTMqyBHhmzE4tyZv03xMGzVqRZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B2sGFq7wzk54kFUE8KHL5QB53Q3e0iPUQsP61CKd0swdL70Il2v3HNaT2kSQ0U6fXy bLNaiXS/lm7lpAx2HmBlSLaIuvudovsmTxrYCeVMkXfqJEhTMdydreT3Mfywy2iLAa/m FEmroRhDS2aIliG7yOB23jPZZic/pjA5DgT9Q= MIME-Version: 1.0 Received: by 10.142.144.9 with SMTP id r9mr2752781wfd.294.1235516300712; Tue, 24 Feb 2009 14:58:20 -0800 (PST) In-Reply-To: References: <200902240058.31212.kstewart@owt.com> Date: Tue, 24 Feb 2009 17:58:20 -0500 Message-ID: <47d0403c0902241458m32738f53l58ef878ff61c8478@mail.gmail.com> From: Ben Kaduk To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:23:28 -0000 On Tue, Feb 24, 2009 at 5:53 PM, Warren Block wrote: > > I guess I just don't understand. Why did that file and so many others in > /etc go backwards: > > 7.1-RELEASE had 1.3.6.1 2008/11/25 > > Three months later: > > RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 > > Were those later versions (maybe just version strings) included in > 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change > is just fixing that error? I think the 2008/11/25 date is from when RELENG_7_1 was branched --- the branch took place after the file was created, so it looks newer, even though the content is the same. -Ben Kaduk From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 23:23:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C10C1065686 for ; Tue, 24 Feb 2009 23:23:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 70DF38FC2C for ; Tue, 24 Feb 2009 23:23:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1ONNRY4038419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 09:53:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: pluknet Date: Wed, 25 Feb 2009 09:53:03 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200902241956.46306.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4593394.lrEYdeWD3z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902250953.20666.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: E7400 Speedstep support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:23:34 -0000 --nextPart4593394.lrEYdeWD3z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 February 2009 06:43:33 pluknet wrote: > May those error messages be BIOS related? > From my E7200 (well, this is from -current): Could be, bubt I have the latest BIOS.. > cpu0: on acpi0 > ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - CF, > should be C6 [20070320] > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > p4tcc1: on cpu1 > > dev.cpu has also expected values. Hmm OK, but maybe the 7400 hasn't been added? (or I have a different rev or= =20 something..) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4593394.lrEYdeWD3z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJpIFZ5ZPcIHs/zowRAtnIAJwOVYoBIT0YSD7kHIms7VMBXL0udwCeOLgm WsAXxXcTPrZh6ZMfh0MoIew= =o2Xf -----END PGP SIGNATURE----- --nextPart4593394.lrEYdeWD3z-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 23:24:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3695B1065697 for ; Tue, 24 Feb 2009 23:24:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 58EB08FC18 for ; Tue, 24 Feb 2009 23:24:38 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1ONOWZt038550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 09:54:33 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Robert Noland Date: Wed, 25 Feb 2009 09:54:20 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200902231200.38164.doconnor@gsoft.com.au> <200902242105.05667.doconnor@gsoft.com.au> <1235502609.1273.27.camel@widget.2hip.net> In-Reply-To: <1235502609.1273.27.camel@widget.2hip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2318436.QiBaxLLWbI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902250954.21944.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Intel Q45 problems on 7.1-STABLE (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:24:40 -0000 --nextPart2318436.QiBaxLLWbI Content-Type: multipart/mixed; boundary="Boundary-01=_lGIpJ4KIDed2CCJ" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_lGIpJ4KIDed2CCJ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 February 2009 05:40:09 Robert Noland wrote: > > The reported value of stolen memory is still wrong however. > > Hrm, I wonder if I have missed an MFC... Please send me some logs and > additional details. > > Your -STABLE is current right? It's about a week or so old. I can update it if you like (or I can let you know specific revs) I've attached dmesg and Xorg log, although the former is truncated due to=20 verbose booting.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Boundary-01=_lGIpJ4KIDed2CCJ Content-Type: text/plain; charset="utf-8"; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x2e10, revid=3D0x03 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2e12, revid=3D0x03 domain=3D0, bus=3D0, slot=3D2, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xd0000000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xc0000000, size 28, ena= bled map[20]: type I/O Port, range 32, base 0xf1c0, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x2e13, revid=3D0x03 domain=3D0, bus=3D0, slot=3D2, func=3D1 class=3D03-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xd0400000, size 20, enabled found-> vendor=3D0x8086, dev=3D0x10de, revid=3D0x02 domain=3D0, bus=3D0, slot=3D25, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd0600000, size 17, enabled map[14]: type Memory, range 32, base 0xd0624000, size 12, enabled map[18]: type I/O Port, range 32, base 0xf0e0, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=3D0x8086, dev=3D0x3a67, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0xf0c0, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x3a68, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D3 map[20]: type I/O Port, range 32, base 0xf0a0, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x3a69, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0xf080, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x3a6c, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd0625400, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x3a6e, revid=3D0x02 domain=3D0, bus=3D0, slot=3D27, func=3D0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xd0620000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x3a64, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D3 map[20]: type I/O Port, range 32, base 0xf060, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x3a65, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0xf040, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=3D0x8086, dev=3D0x3a66, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0xf020, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x3a6a, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd0625000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x3a14, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x3a00, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D2 class=3D01-01-8f, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xf1b0, size 3, enabled map[14]: type I/O Port, range 32, base 0xf1a0, size 2, enabled map[18]: type I/O Port, range 32, base 0xf190, size 3, enabled map[1c]: type I/O Port, range 32, base 0xf180, size 2, enabled map[20]: type I/O Port, range 32, base 0xf170, size 4, enabled map[24]: type I/O Port, range 32, base 0xf160, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=3D0x8086, dev=3D0x3a60, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[10]: type Memory, range 64, base 0xd0625800, size 8, enabled map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x3a06, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D5 class=3D01-01-85, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xf150, size 3, enabled map[14]: type I/O Port, range 32, base 0xf140, size 2, enabled map[18]: type I/O Port, range 32, base 0xf130, size 3, enabled map[1c]: type I/O Port, range 32, base 0xf120, size 2, enabled map[20]: type I/O Port, range 32, base 0xf110, size 4, enabled map[24]: type I/O Port, range 32, base 0xf100, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0xf1c0-0xf1c7 mem 0xd0000000-0xd03ff= fff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xc0000000 vgapci0: Reserved 0x400000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: detected 32764k stolen memory agp0: aperture size is 256M vgapci1: mem 0xd0400000-0xd04fffff at device 2.1 o= n pci0 em0: port 0xf0e0-0xf0ff mem 0x= d0600000-0xd061ffff,0xd0624000-0xd0624fff irq 20 at device 25.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd0600000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xd0624000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1c:c0:9d:2e:47 uhci0: port 0xf0c0-0xf0df irq 16 at device = 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf0c0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xf0a0-0xf0bf irq 21 at device = 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf0a0 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 51 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xf080-0xf09f irq 18 at device = 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf080 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd0625400-0xd06257ff irq 18= at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd0625400 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: waiting for BIOS to give up control usb3: timed out waiting for BIOS usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered hdac0: mem 0xd0620000-0x= d0623fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0620000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53 hdac0: [MPSAFE] hdac0: [ITHREAD] uhci3: port 0xf060-0xf07f irq 23 at device = 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf060 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xf040-0xf05f irq 19 at device = 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf040 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 55 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xf020-0xf03f irq 18 at device = 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xf020 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xd0625000-0xd06253ff irq 23= at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd0625000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: waiting for BIOS to give up control usb7: timed out waiting for BIOS usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered umass0: on uhub7 umass0:0:0:-1: Attached to scbus0 pcib1: at device 30.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd0500000-0xd05fffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x11c1, dev=3D0x5811, revid=3D0x70 domain=3D0, bus=3D1, slot=3D1, func=3D0 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd0500000, size 12, enabled pcib1: requested memory range 0xd0500000-0xd0500fff: good map[14]: type Memory, range 32, base 0xd0501000, size 8, enabled pcib1: requested memory range 0xd0501000-0xd05010ff: good pcib1: matched entry for 1.1.INTA pcib1: slot 1 INTA hardwired to IRQ 22 fwohci0: mem 0xd0500000-0xd0500fff,0xd0501000-0xd05010ff= irq 22 at device 1.0 on pci1 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0500000 fwohci0: [MPSAFE] fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=3D0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:02:41:76:6b 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:90:27:41:76:6b fwe0: bpf attached fwe0: Ethernet address: 02:90:27:41:76:6b fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:90:27:00:02:41:76:6b @ 0xfffe00000000, S400, ma= xrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12d4000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf1b0-0xf1b7,0xf1a0-0xf1a3,= 0xf190-0xf197,0xf180-0xf183,0xf170-0xf17f,0xf160-0xf16f irq 19 at device 31= =2E2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf170 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xf160 ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf1b0 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf1a0 ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata2: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xf190 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xf180 ata3: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata3: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf150-0xf157,0xf140-0xf143,= 0xf130-0xf137,0xf120-0xf123,0xf110-0xf11f,0xf100-0xf10f irq 19 at device 31= =2E5 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf110 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0xf100 ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xf150 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xf140 ata4: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata4: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xf130 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xf120 ata5: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat0=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: stat1=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata5: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata5: [MPSAFE] ata5: [ITHREAD] acpi_button0: on acpi0 acpi_button1: on acpi0 sio0: irq maps: 0xc09 0xc19 0xc09 0xc09 sio0: irq maps: 0xc09 0xc19 0xc09 0xc09 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] cpu0: on acpi0 est0: on cpu0 est0: Guessed bus clock (high) of 37 MHz est0: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Guessed bus clock (high) of 37 MHz est1: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est1 attach returned 6 p4tcc1: on cpu1 ahc_isa_probe 0: ioport 0xc00 alloc failed ex_isa_identify() sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xcc800-0xcd7ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff ioapic0: routing intpin 14 (ISA IRQ 14) to vector 57 ata0: [MPSAFE] ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 58 ata1: [MPSAFE] ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 59 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 60 ppbus0: [MPSAFE] ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag plip0: bpf attached ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xc29 0xc29 0xc29 0xc29 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices ukbd0: on uhub2 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 uhid0: on uhub2 ums0: on uhub2 ums0: 3 buttons and Z dir. Device configuration finished. Reducing kern.maxvnodes 131612 -> 100000 procfs registered lapic: Divisor 2, Frequency 133338884 hz Timecounter "TSC" frequency 2800116511 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedfirewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) hptrr: no controller detected. ata2-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad4: 238475MB at ata2-master SATA300 ad4: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed GEOM_LABEL: Label for provider ad4s1 is ntfs/XPPro. GEOM_LABEL: Label for provider ad4s2a is ufs/slash. GEOM_LABEL: Label for provider ad4s2d is ufs/var. GEOM_LABEL: Label for provider ad4s2e is ufs/usr. ata3: reiniting channel .. ata3: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata3: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata3: reinit done .. ata3: reiniting channel .. ata3: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata3: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata3: reset tp2 stat0=3D00 stat1=3D00 devices=3D0xc ata3: reinit done .. ata3-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D40 wire acd0: DVDR drive at ata3 as master acd0: read 8269KB/s (8269KB/s) write 8269KB/s (8269KB/s), 2048KB buffer, SA= TA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc hdac0: Probing codec #2... hdac0: HDA Codec #2: Analog Devices AD1882 hdac0: HDA Codec ID: 0x11d41882 hdac0: Vendor: 0x11d4 hdac0: Device: 0x1882 hdac0: Revision: 0x03 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0x10038086 hdac0: Found audio FG nid=3D1 startnode=3D2 endnode=3D61 total=3D59 hdac0:=20 hdac0: Processing audio FG cad=3D2 nid=3D1... hdac0: GPIO: 0x40000002 NumGPIO=3D2 NumGPO=3D0 NumGPI=3D0 GPIWake=3D0 GPIUn= sol=3D1 hdac0: nid 17 0x02214030 as 3 seq 0 Headphones Jack jack 1 loc 2 c= olor Green misc 0 hdac0: nid 18 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 c= olor Green misc 0 hdac0: nid 19 0x511711f0 as 15 seq 0 Speaker None jack 7 loc 17 c= olor Black misc 1 hdac0: nid 20 0x02a19040 as 4 seq 0 Mic Jack jack 1 loc 2 c= olor Pink misc 0 hdac0: nid 21 0x0181302e as 2 seq 14 Line-in Jack jack 1 loc 1 c= olor Blue misc 0 hdac0: nid 22 0x41011012 as 1 seq 2 Line-out None jack 1 loc 1 c= olor Black misc 0 hdac0: nid 23 0x01a19020 as 2 seq 0 Mic Jack jack 1 loc 1 c= olor Pink misc 0 hdac0: nid 24 0x59331122 as 2 seq 2 CD None jack 3 loc 25 c= olor Black misc 1 hdac0: Patching widget caps nid=3D26 0x00400000 -> 0x00700000 hdac0: nid 27 0x4145f1a0 as 10 seq 0 SPDIF-out None jack 5 loc 1 c= olor Other misc 1 hdac0: GHOST: nid=3D29 j=3D0 entnum=3D4 index=3D0 res=3D0x00000b01 hdac0: Adding 58 (nid=3D35): Max connection reached! max=3D32 hdac0: nid 36 0x41016011 as 1 seq 1 Line-out None jack 1 loc 1 c= olor Orange misc 0 hdac0: Patched pins configuration: hdac0: nid 17 0x02214030 as 3 seq 0 Headphones Jack jack 1 loc 2 c= olor Green misc 0 hdac0: nid 18 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 c= olor Green misc 0 hdac0: nid 19 0x511711f0 as 15 seq 0 Speaker None jack 7 loc 17 c= olor Black misc 1 [DISABLED] hdac0: nid 20 0x02a19040 as 4 seq 0 Mic Jack jack 1 loc 2 c= olor Pink misc 0 hdac0: nid 21 0x0181302e as 2 seq 14 Line-in Jack jack 1 loc 1 c= olor Blue misc 0 hdac0: nid 22 0x41011012 as 1 seq 2 Line-out None jack 1 loc 1 c= olor Black misc 0 [DISABLED] hdac0: nid 23 0x01a19020 as 2 seq 0 Mic Jack jack 1 loc 1 c= olor Pink misc 0 hdac0: nid 24 0x59331122 as 2 seq 2 CD None jack 3 loc 25 c= olor Black misc 1 [DISABLED] hdac0: nid 27 0x4145f1a0 as 10 seq 0 SPDIF-out None jack 5 loc 1 c= olor Other misc 1 [DISABLED] hdac0: nid 36 0x41016011 as 1 seq 1 Line-out None jack 1 loc 1 c= olor Orange misc 0 [DISABLED] hdac0: 4 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=3D18 seq=3D0 hdac0: Association 1 (2) in: hdac0: Pin nid=3D23 seq=3D0 hdac0: Pin nid=3D21 seq=3D14 hdac0: Association 2 (3) out: hdac0: Pin nid=3D17 seq=3D0 hdac0: Association 3 (4) in: hdac0: Pin nid=3D20 seq=3D0 hdac0: Tracing association 0 (1) hdac0: Pin 18 traced to DAC 4 hdac0: Association 0 (1) trace succeded hdac0: Tracing association 1 (2) hdac0: Pin 23 traced to ADC 8 hdac0: Pin 21 traced to ADC 8 hdac0: Association 1 (2) trace succeded hdac0: Tracing association 2 (3) hdac0: Pin 17 traced to DAC 3 hdac0: Association 2 (3) trace succeded hdac0: Tracing association 3 (4) hdac0: Pin 20 traced to ADC 9 hdac0: Association 3 (4) trace succeded hdac0: Tracing input monitor hdac0: Tracing nid 32 to out hdac0: nid 32 is input monitor hdac0: Tracing beeper hdac0: nid 26 traced to out hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0:=20 hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0:=20 hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: IN amp: 0x80000000 hdac0: OUT amp: 0x00052727 hdac0:=20 hdac0: nid: 2 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0003031d hdac0: DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e01e0 hdac0: 16 20 24 bits, 44 48 88 96 KHz hdac0: Output amp: 0x80052727 hdac0: mute=3D1 step=3D39 size=3D5 offset=3D39 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D29 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 3 hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: Output amp: 0x00052727 hdac0: mute=3D0 step=3D39 size=3D5 offset=3D39 hdac0:=20 hdac0: nid: 4 hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: Output amp: 0x00052727 hdac0: mute=3D0 step=3D39 size=3D5 offset=3D39 hdac0:=20 hdac0: nid: 5 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: Output amp: 0x00052727 hdac0: mute=3D0 step=3D39 size=3D5 offset=3D39 hdac0:=20 hdac0: nid: 6 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x00100501 hdac0: PWR STEREO hdac0: Association: 1 (0x00004001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D12 [audio selector] hdac0:=20 hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x00100501 hdac0: PWR STEREO hdac0: Association: 3 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e01ff hdac0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D13 [audio selector] hdac0:=20 hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 11 [DISABLED] hdac0: Name: audio selector hdac0: Widget cap: 0x00300301 hdac0: DIGITAL STEREO hdac0: connections: 2 hdac0: | hdac0: + <- nid=3D8 [audio input] (selected) hdac0: + <- nid=3D9 [audio input] hdac0:=20 hdac0: nid: 12 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: line, mix, monitor hdac0: Output amp: 0x80053627 hdac0: mute=3D1 step=3D54 size=3D5 offset=3D39 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=3D17 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=3D57 [audio selector] hdac0: + <- nid=3D58 [audio selector] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + <- nid=3D60 [audio selector] (selected) hdac0: + [DISABLED] <- nid=3D24 [pin: CD (None)] [DISABLED] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D18 [pin: Line-out (Green Jack)] hdac0: + <- nid=3D32 [audio mixer] hdac0:=20 hdac0: nid: 13 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: mic, mix hdac0: Output amp: 0x80053627 hdac0: mute=3D1 step=3D54 size=3D5 offset=3D39 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=3D17 [pin: Headphones (Green Jack)] hdac0: + <- nid=3D57 [audio selector] (selected) hdac0: + [DISABLED] <- nid=3D58 [audio selector] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D60 [audio selector] hdac0: + [DISABLED] <- nid=3D24 [pin: CD (None)] [DISABLED] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D18 [pin: Line-out (Green Jack)] hdac0: + <- nid=3D32 [audio mixer] hdac0:=20 hdac0: nid: 14 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 15 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 16 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x800b0f0f hdac0: mute=3D1 step=3D15 size=3D11 offset=3D15 hdac0:=20 hdac0: nid: 17 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x0000003f hdac0: ISC TRQD PDC HP OUT IN hdac0: Pin config: 0x02214030 hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D34 [audio mixer] hdac0:=20 hdac0: nid: 18 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003f hdac0: ISC TRQD PDC HP OUT IN EAPD hdac0: Pin config: 0x01014010 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D41 [audio mixer] hdac0:=20 hdac0: nid: 19 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040050c hdac0: PWR hdac0: Pin cap: 0x00010010 hdac0: OUT EAPD hdac0: Pin config: 0x511711f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80051f1f hdac0: mute=3D1 step=3D31 size=3D5 offset=3D31 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=3D45 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 20 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x00400081 hdac0: UNSOL STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00003727 hdac0: ISC TRQD PDC IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x02a19040 hdac0: Pin control: 0x00000025 IN VREFs hdac0:=20 hdac0: nid: 21 hdac0: Name: pin: Line-in (Blue Jack) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: line (line) hdac0: Pin cap: 0x00003737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x0181302e hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=3D44 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x0040018d hdac0: UNSOL STEREO hdac0: Pin cap: 0x00000017 hdac0: ISC TRQD PDC OUT hdac0: Pin config: 0x41011012 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=3D42 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 23 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040098d hdac0: LRSWAP UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00003737 hdac0: ISC TRQD PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac0: Pin config: 0x01a19020 hdac0: Pin control: 0x00000025 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=3D38 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 24 [DISABLED] hdac0: Name: pin: CD (None) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x59331122 hdac0: Pin control: 0x00000000 hdac0:=20 hdac0: nid: 25 [DISABLED] hdac0: Name: power widget hdac0: Widget cap: 0x00500500 hdac0: PWR hdac0: connections: 2 hdac0: | hdac0: + <- nid=3D32 [audio mixer] (selected) hdac0: + <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 26 hdac0: Name: beep widget hdac0: Widget cap: 0x00700000 hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0:=20 hdac0: nid: 27 [DISABLED] hdac0: Name: pin: SPDIF-out (None) hdac0: Widget cap: 0x00400301 hdac0: DIGITAL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x4145f1a0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D2 [audio output] [DISABLED] hdac0:=20 hdac0: nid: 28 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 29 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200303 hdac0: DIGITAL STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D1 [GHOST!] [UNKNOWN] hdac0: + [DISABLED] <- nid=3D11 [audio selector] [DISABLED] hdac0:=20 hdac0: nid: 30 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D4 [audio output] hdac0: + [DISABLED] <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00301 hdac0: DIGITAL STEREO hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D2 [audio output] [DISABLED] hdac0:=20 hdac0: nid: 32 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00004001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=3D1 step=3D31 size=3D5 offset=3D23 hdac0: connections: 8 hdac0: | hdac0: + <- nid=3D57 [audio selector] hdac0: + <- nid=3D58 [audio selector] hdac0: + [DISABLED] <- nid=3D17 [pin: Headphones (Green Jack)] hdac0: + [DISABLED] <- nid=3D18 [pin: Line-out (Green Jack)] hdac0: + <- nid=3D60 [audio selector] hdac0: + [DISABLED] <- nid=3D59 [vendor widget] [DISABLED] hdac0: + [DISABLED] <- nid=3D24 [pin: CD (None)] [DISABLED] hdac0: + <- nid=3D26 [beep widget] hdac0:=20 hdac0: nid: 33 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: OSS: mix hdac0: Output amp: 0x80051f1f hdac0: mute=3D1 step=3D31 size=3D5 offset=3D31 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D32 [audio mixer] hdac0:=20 hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3D55 [audio selector] hdac0: + <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 35 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00100 hdac0: connections: 32 hdac0: | hdac0: + <- nid=3D17 [pin: Headphones (Green Jack)] (selected) hdac0: + <- nid=3D18 [pin: Line-out (Green Jack)] hdac0: + [DISABLED] <- nid=3D19 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=3D20 [pin: Mic (Pink Jack)] hdac0: + <- nid=3D21 [pin: Line-in (Blue Jack)] hdac0: + [DISABLED] <- nid=3D22 [pin: Line-out (None)] [DISABLED] hdac0: + <- nid=3D23 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=3D24 [pin: CD (None)] [DISABLED] hdac0: + <- nid=3D32 [audio mixer] hdac0: + <- nid=3D33 [audio selector] hdac0: + <- nid=3D34 [audio mixer] hdac0: + [DISABLED] <- nid=3D36 [pin: Line-out (None)] [DISABLED] hdac0: + <- nid=3D37 [vendor widget] [DISABLED] hdac0: + <- nid=3D38 [audio mixer] [DISABLED] hdac0: + <- nid=3D39 [audio mixer] [DISABLED] hdac0: + <- nid=3D40 [vendor widget] [DISABLED] hdac0: + <- nid=3D41 [audio mixer] hdac0: + <- nid=3D42 [audio mixer] [DISABLED] hdac0: + <- nid=3D43 [vendor widget] [DISABLED] hdac0: + <- nid=3D44 [audio mixer] [DISABLED] hdac0: + <- nid=3D45 [audio mixer] [DISABLED] hdac0: + <- nid=3D46 [vendor widget] [DISABLED] hdac0: + <- nid=3D48 [vendor widget] [DISABLED] hdac0: + <- nid=3D49 [vendor widget] [DISABLED] hdac0: + <- nid=3D50 [vendor widget] [DISABLED] hdac0: + <- nid=3D51 [vendor widget] [DISABLED] hdac0: + <- nid=3D52 [vendor widget] [DISABLED] hdac0: + <- nid=3D53 [vendor widget] [DISABLED] hdac0: + <- nid=3D54 [vendor widget] [DISABLED] hdac0: + <- nid=3D55 [audio selector] hdac0: + <- nid=3D56 [vendor widget] [DISABLED] hdac0: + <- nid=3D57 [audio selector] hdac0:=20 hdac0: nid: 36 [DISABLED] hdac0: Name: pin: Line-out (None) hdac0: Widget cap: 0x0040098d hdac0: LRSWAP UNSOL STEREO hdac0: Pin cap: 0x00000017 hdac0: ISC TRQD PDC OUT hdac0: Pin config: 0x41016011 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=3D39 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 38 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D5 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 39 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D5 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 40 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 41 hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3D4 [audio output] hdac0: + <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 42 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D3 [audio output] hdac0: + [DISABLED] <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 43 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 44 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200103 hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=3D1 step=3D0 size=3D0 offset=3D0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3D3 [audio output] hdac0: + [DISABLED] <- nid=3D33 [audio selector] hdac0:=20 hdac0: nid: 45 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x00200100 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D30 [audio mixer] [DISABLED] hdac0:=20 hdac0: nid: 46 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 47 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00100 hdac0: connections: 3 hdac0: | hdac0: + <- nid=3D20 [pin: Mic (Pink Jack)] (selected) hdac0: + <- nid=3D21 [pin: Line-in (Blue Jack)] hdac0: + <- nid=3D23 [pin: Mic (Pink Jack)] hdac0:=20 hdac0: nid: 48 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 49 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 50 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 51 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 52 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 53 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 54 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 55 hdac0: Name: audio selector hdac0: Widget cap: 0x00300101 hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm hdac0: connections: 2 hdac0: | hdac0: + <- nid=3D3 [audio output] (selected) hdac0: + [DISABLED] <- nid=3D4 [audio output] hdac0:=20 hdac0: nid: 56 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 57 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 3 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270300 hdac0: mute=3D0 step=3D3 size=3D39 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D20 [pin: Mic (Pink Jack)] hdac0:=20 hdac0: nid: 58 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: line hdac0: Output amp: 0x00270300 hdac0: mute=3D0 step=3D3 size=3D39 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D21 [pin: Line-in (Blue Jack)] hdac0:=20 hdac0: nid: 59 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0:=20 hdac0: nid: 60 hdac0: Name: audio selector hdac0: Widget cap: 0x0030010d hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: monitor hdac0: Output amp: 0x00270300 hdac0: mute=3D0 step=3D3 size=3D39 offset=3D0 hdac0: connections: 1 hdac0: | hdac0: + <- nid=3D23 [pin: Mic (Pink Jack)] hdac0:=20 pcm0: at cad 2 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0:=20 pcm0: Playback: pcm0:=20 pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e01ff pcm0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz pcm0: DAC: 4 pcm0:=20 pcm0: Record: pcm0:=20 pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e01ff pcm0: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz pcm0: ADC: 8 pcm0:=20 pcm0: +--------------------------------+ pcm0: | DUMPING Playback/Record Pathes | pcm0: +--------------------------------+ pcm0:=20 pcm0: Playback: pcm0:=20 pcm0: nid=3D18 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=3D41 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=3D4 [audio output] [src: pcm] pcm0: + <- nid=3D33 [audio selector] [src: mix] pcm0: | pcm0: + <- nid=3D32 [audio mixer] [src: mix] pcm0:=20 pcm0: Record: pcm0:=20 pcm0: nid=3D8 [audio input] pcm0: | pcm0: + <- nid=3D12 [audio selector] [src: line, mix, monitor] pcm0: | pcm0: + <- nid=3D58 [audio selector] [src: line] pcm0: | pcm0: + <- nid=3D21 [pin: Line-in (Blue Jack)] [src: li= ne] pcm0: + <- nid=3D60 [audio selector] [src: monitor] pcm0: | pcm0: + <- nid=3D23 [pin: Mic (Pink Jack)] [src: monito= r] pcm0: + <- nid=3D32 [audio mixer] [src: mix] pcm0:=20 pcm0: Input Mix: pcm0:=20 pcm0: nid=3D32 [audio mixer] pcm0: | pcm0: + <- nid=3D57 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=3D20 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=3D58 [audio selector] [src: line] pcm0: | pcm0: + <- nid=3D21 [pin: Line-in (Blue Jack)] [src: line] pcm0: + <- nid=3D60 [audio selector] [src: monitor] pcm0: | pcm0: + <- nid=3D23 [pin: Mic (Pink Jack)] [src: monitor] pcm0: + <- nid=3D26 [beep widget] [src: speaker] pcm0:=20 pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0:=20 pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 3 (nid 4 out): -58/0dB (40 steps) pcm0: +- ctl 9 (nid 18 in ): mute pcm0: +- ctl 33 (nid 41 in 0): mute pcm0: +- ctl 34 (nid 41 in 1): mute pcm0:=20 pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 3 (nid 4 out): -58/0dB (40 steps) pcm0: +- ctl 33 (nid 41 in 0): mute pcm0:=20 pcm0: Microphone2 Volume (OSS: monitor) pcm0: | pcm0: +- ctl 41 (nid 60 out): 0/30dB (4 steps) pcm0:=20 pcm0: Line-in Volume (OSS: line) pcm0: | pcm0: +- ctl 40 (nid 58 out): 0/30dB (4 steps) pcm0:=20 pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 7 (nid 16 out): -45/0dB (16 steps) + mute pcm0: +- ctl 24 (nid 32 in 7): -34/12dB (32 steps) + mute pcm0:=20 pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 5 (nid 12 out): -58/22dB (55 steps) + mute pcm0:=20 pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 17 (nid 32 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 18 (nid 32 in 1): -34/12dB (32 steps) + mute pcm0: +- ctl 21 (nid 32 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 24 (nid 32 in 7): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 33 out): -46/0dB (32 steps) + mute pcm0: +- ctl 34 (nid 41 in 1): mute pcm0:=20 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 1530000, 4000; 0xe5b92000 -> 1530000 pcm0: sndbuf_setmap 1540000, 4000; 0xe5ba2000 -> 1540000 pcm1: at cad 2 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1:=20 pcm1: Playback: pcm1:=20 pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e01ff pcm1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz pcm1: DAC: 3 pcm1:=20 pcm1: Record: pcm1:=20 pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e01ff pcm1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 KHz pcm1: ADC: 9 pcm1:=20 pcm1: +--------------------------------+ pcm1: | DUMPING Playback/Record Pathes | pcm1: +--------------------------------+ pcm1:=20 pcm1: Playback: pcm1:=20 pcm1: nid=3D17 [pin: Headphones (Green Jack)] pcm1: | pcm1: + <- nid=3D34 [audio mixer] [src: pcm, mix] pcm1: | pcm1: + <- nid=3D55 [audio selector] [src: pcm] pcm1: | pcm1: + <- nid=3D3 [audio output] [src: pcm] pcm1: + <- nid=3D33 [audio selector] [src: mix] pcm1: | pcm1: + <- nid=3D32 [audio mixer] [src: mix] pcm1:=20 pcm1: Record: pcm1:=20 pcm1: nid=3D9 [audio input] pcm1: | pcm1: + <- nid=3D13 [audio selector] [src: mic, mix] pcm1: | pcm1: + <- nid=3D57 [audio selector] [src: mic] pcm1: | pcm1: + <- nid=3D20 [pin: Mic (Pink Jack)] [src: mic] pcm1: + <- nid=3D32 [audio mixer] [src: mix] pcm1:=20 pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1:=20 pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 2 (nid 3 out): -58/0dB (40 steps) pcm1: +- ctl 8 (nid 17 in ): mute pcm1: +- ctl 26 (nid 34 in 0): mute pcm1: +- ctl 27 (nid 34 in 1): mute pcm1:=20 pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 2 (nid 3 out): -58/0dB (40 steps) pcm1: +- ctl 26 (nid 34 in 0): mute pcm1:=20 pcm1: Microphone Volume (OSS: mic) pcm1: | pcm1: +- ctl 39 (nid 57 out): 0/30dB (4 steps) pcm1:=20 pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 6 (nid 13 out): -58/22dB (55 steps) + mute pcm1:=20 pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 27 (nid 34 in 1): mute pcm1:=20 pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "mix": pcm1: Mixer "rec": pcm1: clone manager: deadline=3D750ms flags=3D0x8000001e pcm1: sndbuf_setmap 1560000, 4000; 0xe5bb2000 -> 1560000 pcm1: sndbuf_setmap 1580000, 4000; 0xe5bc2000 -> 1580000 (probe1:sbp0:0:0:0): error 22 (probe1:sbp0:0:0:0): Unretryable Error (probe2:sbp0:0:1:0): error 22 (probe2:sbp0:0:1:0): Unretryable Error (probe3:sbp0:0:2:0): error 22 (probe3:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:3:0): error 22 (probe4:sbp0:0:3:0): Unretryable Error (probe5:sbp0:0:4:0): error 22 (probe5:sbp0:0:4:0): Unretryable Error (probe6:sbp0:0:5:0): error 22 (probe6:sbp0:0:5:0): Unretryable Error (probe7:sbp0:0:6:0): error 22 (probe7:sbp0:0:6:0): Unretryable Error pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device= =20 pass0: 40.000MB/s transfers pass1 at umass-sim0 bus 0 target 0 lun 1 pass1: Removable Direct Access SCSI-0 device= =20 pass1: 40.000MB/s transfers pass2 at umass-sim0 bus 0 target 0 lun 2 pass2: Removable Direct Access SCSI-0 device=20 pass2: 40.000MB/s transfers pass3 at umass-sim0 bus 0 target 0 lun 3 pass3: Removable Direct Access SCSI-0 device=20 pass3: 40.000MB/s transfers GEOM: new disk da0 GEOM: new disk da1 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 1 ioapic0: Assigning PCI IRQ 22 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 1 msi: Assigning MSI IRQ 256 to local APIC 0 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device=20 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da1:umass-sim0:0:0:1): error 6 (da1:umass-sim0:0:0:1): Unretryable Error da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device=20 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da2:umass-sim0:0:0:2): error 6 (da2:umass-sim0:0:0:2): Unretryable Error da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device=20 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present (da3:umass-sim0:0:0:3): error 6 (da3:umass-sim0:0:0:3): Unretryable Error da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device=20 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 (da1:umass-sim0:0:0:1): error 6 (da1:umass-sim0:0:0:1): Unretryable Error Opened disk da1 -> 6 (da1:umass-sim0:0:0:1): error 6 (da1:umass-sim0:0:0:1): Unretryable Error Opened disk da1 -> 6 (da1:umass-sim0:0:0:1): error 6 (da1:umass-sim0:0:0:1): Unretryable Error Opened disk da1 -> 6 (da1:umass-sim0:0:0:1): error 6 (da1:umass-sim0:0:0:1): Unretryable Error Opened disk da1 -> 6 GEOM: new disk da2 GEOM: new disk da3 (da2:umass-sim0:0:0:2): error 6 (da2:umass-sim0:0:0:2): Unretryable Error Opened disk da2 -> 6 (da2:umass-sim0:0:0:2): error 6 (da2:umass-sim0:0:0:2): Unretryable Error Opened disk da2 -> 6 (da2:umass-sim0:0:0:2): error 6 (da2:umass-sim0:0:0:2): Unretryable Error Opened disk da2 -> 6 (da2:umass-sim0:0:0:2): error 6 (da2:umass-sim0:0:0:2): Unretryable Error Opened disk da2 -> 6 (da3:umass-sim0:0:0:3): error 6 (da3:umass-sim0:0:0:3): Unretryable Error Opened disk da3 -> 6 (da3:umass-sim0:0:0:3): error 6 (da3:umass-sim0:0:0:3): Unretryable Error Opened disk da3 -> 6 (da3:umass-sim0:0:0:3): error 6 (da3:umass-sim0:0:0:3): Unretryable Error Opened disk da3 -> 6 (da3:umass-sim0:0:0:3): error 6 (da3:umass-sim0:0:0:3): Unretryable Error Opened disk da3 -> 6 Trying to mount root from ufs:/dev/ufs/slash start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered em0: Link is up 100 Mbps Full Duplex --Boundary-01=_lGIpJ4KIDed2CCJ-- --nextPart2318436.QiBaxLLWbI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJpIGl5ZPcIHs/zowRAlDnAJ9E6GTDAeeT3hOR21Sz31WU55krqQCbBo1Y JtDfgfP4uCGniDjZt6mK2PE= =KdDp -----END PGP SIGNATURE----- --nextPart2318436.QiBaxLLWbI-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 24 23:45:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82025106566B for ; Tue, 24 Feb 2009 23:45:08 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE038FC2B for ; Tue, 24 Feb 2009 23:45:07 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:55421 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Lc6ih-0002cu-4R for freebsd-stable@freebsd.org; Wed, 25 Feb 2009 00:29:47 +0100 Received: (qmail 28305 invoked from network); 25 Feb 2009 00:29:45 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 25 Feb 2009 00:29:45 +0100 Received: (qmail 22904 invoked by uid 1001); 25 Feb 2009 00:29:45 +0100 Date: Wed, 25 Feb 2009 00:29:45 +0100 From: Erik Trulsson To: Warren Block Message-ID: <20090224232945.GA22871@owl.midgard.homeip.net> References: <200902240058.31212.kstewart@owt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1Lc6ih-0002cu-4R. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Lc6ih-0002cu-4R 2734b65cb5716885b4598d0cc2c2ad73 Cc: freebsd-stable@freebsd.org, Kent Stewart Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:45:08 -0000 On Tue, Feb 24, 2009 at 03:53:18PM -0700, Warren Block wrote: > On Tue, 24 Feb 2009, Kent Stewart wrote: > > On Monday 23 February 2009 10:11:45 pm Warren Block wrote: > >> Lately I've installed a couple of test systems from 7.1-RELEASE CDs, > >> then csupped to RELENG_7 from cvsup9: > >> > >> mergemaster adds a *lot* of old files in /etc that were not there in > >> 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a > >> bunch of bluetooth files and /etc/isdn/*. > >> > >> The version numbers and dates in mergemaster look wrong. For example, > >> /etc/bluetooth/hcsecd.conf: > >> > >> # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ > >> # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax > >> Exp $ > >> > >> Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? > > > > You are looking at the version for the 7.1 release version. The RELENG_7 > > version is > > > > Revision 1.3: download - view: text, markup, annotated - select for diffs > > Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax > > Branches: MAIN > > CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, > > RELENG_7_0, RELENG_7, HEAD > > Branch point for: RELENG_7_1 > > Diff to: previous 1.2: preferred, colored > > Changes since revision 1.2: +1 -1 lines > > I guess I just don't understand. Why did that file and so many others > in /etc go backwards: > > 7.1-RELEASE had 1.3.6.1 2008/11/25 > > Three months later: > > RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 > > Were those later versions (maybe just version strings) included in > 7.1-RELEASE by mistake? Were they tagged by mistake and this latest > change is just fixing that error? The tagging itself causes the version number of the file to be updated. This makes the file in -RELEASE *look* newer then the ones in -STABLE even if the contents of the files haven't actually changed. So there is no mistake, just an annoying side-effect of how the svn->cvs export works with regards to tagging. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 00:35:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 862141065672 for ; Wed, 25 Feb 2009 00:35:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9BA8FC0A for ; Wed, 25 Feb 2009 00:35:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.2] (adsl-156-5-199.bna.bellsouth.net [70.156.5.199]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n1P0YVLo007109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 19:34:31 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Daniel O'Connor" In-Reply-To: <200902250954.21944.doconnor@gsoft.com.au> References: <200902231200.38164.doconnor@gsoft.com.au> <200902242105.05667.doconnor@gsoft.com.au> <1235502609.1273.27.camel@widget.2hip.net> <200902250954.21944.doconnor@gsoft.com.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9sFK66ncPdAMUV20auV3" Organization: FreeBSD Date: Tue, 24 Feb 2009 18:35:45 -0600 Message-Id: <1235522145.1273.63.camel@widget.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-stable@freebsd.org Subject: Re: Intel Q45 problems on 7.1-STABLE (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 00:35:54 -0000 --=-9sFK66ncPdAMUV20auV3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-02-25 at 09:54 +1030, Daniel O'Connor wrote: > On Wednesday 25 February 2009 05:40:09 Robert Noland wrote: > > > The reported value of stolen memory is still wrong however. > > > > Hrm, I wonder if I have missed an MFC... Please send me some logs and > > additional details. > > > > Your -STABLE is current right? >=20 > It's about a week or so old. > I can update it if you like (or I can let you know specific revs) That is new enough. > I've attached dmesg and Xorg log, although the former is truncated due to= =20 > verbose booting.. The code all looks correct based on the Q45 docs. I can only assume that the BIOS is still not doing the right thing for your settings. robert. --=20 Robert Noland FreeBSD --=-9sFK66ncPdAMUV20auV3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmkkmEACgkQM4TrQ4qfRONriQCfWZMSRHVDqrkNDRsqSWH40+KO U4MAnRuJHDh05S4qpTCmXIum8JWZU7Bx =U3ah -----END PGP SIGNATURE----- --=-9sFK66ncPdAMUV20auV3-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 01:26:28 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22401065673; Wed, 25 Feb 2009 01:26:28 +0000 (UTC) (envelope-from STEVE@STEVENWILLS.COM) Received: from mouf.net (mouf.net [208.86.224.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC2B8FC22; Wed, 25 Feb 2009 01:26:28 +0000 (UTC) (envelope-from STEVE@STEVENWILLS.COM) Received: from [10.0.1.198] (cpe-069-134-142-204.nc.res.rr.com [69.134.142.204]) (authenticated bits=0) by mouf.net (8.14.2/8.14.2) with ESMTP id n1P1CI2T083621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2009 20:12:20 -0500 (EST) (envelope-from STEVE@STEVENWILLS.COM) Message-Id: From: Steve Wills To: stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 20:12:18 -0500 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mouf.net [208.86.224.195]); Tue, 24 Feb 2009 20:12:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/9041/Tue Feb 24 11:21:07 2009 on mouf.net X-Virus-Status: Clean Cc: yongari@freebsd.org Subject: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:26:29 -0000 Hi, I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives "re0: PHY read failed" over and over. Does anyone have a suggestion on how to debug? Thanks, Steve From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 03:34:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3C9106564A for ; Wed, 25 Feb 2009 03:34:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 64F728FC08 for ; Wed, 25 Feb 2009 03:34:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 26144 invoked by uid 399); 25 Feb 2009 03:34:24 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Feb 2009 03:34:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49A4BC40.1080301@FreeBSD.org> Date: Tue, 24 Feb 2009 19:34:24 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Warren Block References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:34:30 -0000 Warren Block wrote: > Lately I've installed a couple of test systems from 7.1-RELEASE CDs, > then csupped to RELENG_7 from cvsup9: > > *default host=cvsup9.FreeBSD.org > *default base=/var/db > *default prefix=/usr > *default release=cvs tag=RELENG_7 > *default delete use-rel-suffix That looks right. > mergemaster adds a *lot* of old files in /etc that were not there in > 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a > bunch of bluetooth files and /etc/isdn/*. That is definitely not the outcome you should have ended up with. I just checked both the official svn repo and the official cvs repo and the files they are passing out for the two relevant branches are correct, and the real differences (not $Id tags) between the files in the two branches are what I expected to see. Therefore, the problem is somewhere downstream. > This looks like an error, but maybe I'm missing something. And other > cvsup mirrors seem to agree with cvsup9. My suggestion to you would be to move all source trees that you may have currently somewhere else, move aside /var/db/sup, then start over from scratch and see if what you get is what you expect. If that doesn't work, please script your mergemaster session and send us the output. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 03:37:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751931065677 for ; Wed, 25 Feb 2009 03:37:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0ADAB8FC1B for ; Wed, 25 Feb 2009 03:37:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 29940 invoked by uid 399); 25 Feb 2009 03:37:02 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Feb 2009 03:37:02 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <49A4BCDE.9070807@FreeBSD.org> Date: Tue, 24 Feb 2009 19:37:02 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Torfinn Ingolfsen References: <200902240058.31212.kstewart@owt.com> <20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20090224234756.cd59ce2d.torfinn.ingolfsen@broadpark.no> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:37:04 -0000 Torfinn Ingolfsen wrote: > On Tue, 24 Feb 2009 00:58:31 -0800 > Kent Stewart wrote: > >> You are looking at the version for the 7.1 release version. The >> RELENG_7 version is > > The real question is: why are the files in 7.1-release newer than those > in RELENG_7? They aren't. At least not in the master svn and cvs repositories. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 03:42:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1DD1065673; Wed, 25 Feb 2009 03:42:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3F70B8FC1A; Wed, 25 Feb 2009 03:42:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1P3giSO051324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 14:12:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Robert Noland Date: Wed, 25 Feb 2009 14:12:23 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200902231200.38164.doconnor@gsoft.com.au> <200902250954.21944.doconnor@gsoft.com.au> <1235522145.1273.63.camel@widget.2hip.net> In-Reply-To: <1235522145.1273.63.camel@widget.2hip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2423006.aCMRXg3XVb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902251412.33822.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Intel Q45 problems on 7.1-STABLE (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:42:47 -0000 --nextPart2423006.aCMRXg3XVb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 25 February 2009 11:05:45 Robert Noland wrote: > > I've attached dmesg and Xorg log, although the former is truncated due = to > > verbose booting.. > > The code all looks correct based on the Q45 docs. I can only assume > that the BIOS is still not doing the right thing for your settings. How annoying since it's an Intel product you'd hope they could get it right= :( Thanks. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2423006.aCMRXg3XVb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJpL4h5ZPcIHs/zowRAkxBAJ9RhLBjW632HeucZVv6J+HiYXNEiQCdGmRE jhsqEzguluHY+sLyldNQjnk= =kQYo -----END PGP SIGNATURE----- --nextPart2423006.aCMRXg3XVb-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 06:19:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F0A106566B for ; Wed, 25 Feb 2009 06:19:00 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id E846A8FC0C for ; Wed, 25 Feb 2009 06:18:59 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n1P6IvHL020968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Feb 2009 22:18:57 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4CAE21CC0B; Tue, 24 Feb 2009 22:18:57 -0800 (PST) To: Guy Helmer In-reply-to: Your message of "Tue, 24 Feb 2009 15:46:28 CST." <49A46AB4.3080003@palisadesys.com> Date: Tue, 24 Feb 2009 22:18:57 -0800 From: "Kevin Oberman" Message-Id: <20090225061857.4CAE21CC0B@ptavv.es.net> Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:19:00 -0000 > Date: Tue, 24 Feb 2009 15:46:28 -0600 > From: Guy Helmer > Sender: owner-freebsd-stable@freebsd.org > > I think I may have found a clue regarding some of the hangs I'm seeing > on FreeBSD 7.1. > I have a program (kvoop), compiled under FreeBSD 6 and using > compatibility libraries under FreeBSD 7, that seems to be consistently > involved during these hangs. This time, I noticed that many processes > are stopped, waiting on the ufs lock. I can't tell for certain, but I > assume this kvoop process 33203 is blocking the other processes. The > kvoop process looks to me like it is waiting for a mutex, but nothing > shows up being deadlocked. Am I on the right track? Is there something > else I should be looking for? For whatever it is worth, I have seen this three times over the past couple of weeks. My system is RELENG_7 of Feb. 7. I have no real information to add other than that I have also had this problem. When it happens, the only way out is a reboot. It hit me twice while updating Xorg. Thanks for your efforts! I hope someone can track down what is triggering with this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 08:22:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ED991065670 for ; Wed, 25 Feb 2009 08:22:41 +0000 (UTC) (envelope-from prvs=030766075b=ob@gruft.de) Received: from obh.snafu.de (v6.gruft.de [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id BC8778FC1C for ; Wed, 25 Feb 2009 08:22:40 +0000 (UTC) (envelope-from prvs=030766075b=ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LcF2O-000Hpa-0B for freebsd-stable@freebsd.org; Wed, 25 Feb 2009 09:22:40 +0100 Date: Wed, 25 Feb 2009 09:22:39 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20090225082239.GY79003@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Oliver Brandmueller Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:22:41 -0000 Hi, On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > booting, re0 works for only a short time, then gives "re0: PHY read > failed" over and over. Does anyone have a suggestion on how to debug? The Patch from <20090213113955.GE12653@michelle.cdnetworks.co.kr> (Thread: "fun with re", Feb 13 on this list) helped for me. You may try it and could also give feedback so it gets included. - Olli -- | 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-stable@FreeBSD.ORG Wed Feb 25 08:25:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDC201065687 for ; Wed, 25 Feb 2009 08:25:00 +0000 (UTC) (envelope-from prvs=030766075b=ob@gruft.de) Received: from obh.snafu.de (v6.gruft.de [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99BD08FC2E for ; Wed, 25 Feb 2009 08:25:00 +0000 (UTC) (envelope-from prvs=030766075b=ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LcF4d-000Hrh-T6 for freebsd-stable@freebsd.org; Wed, 25 Feb 2009 09:24:59 +0100 Date: Wed, 25 Feb 2009 09:24:59 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20090225082459.GZ79003@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <20090225082239.GY79003@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090225082239.GY79003@e-Gitt.NET> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Oliver Brandmueller Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:25:01 -0000 Hi, On Wed, Feb 25, 2009 at 09:22:39AM +0100, Oliver Brandmueller wrote: > On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > > I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > > booting, re0 works for only a short time, then gives "re0: PHY read > > failed" over and over. Does anyone have a suggestion on how to debug? > > The Patch from <20090213113955.GE12653@michelle.cdnetworks.co.kr> > (Thread: "fun with re", Feb 13 on this list) helped for me. You may try > it and could also give feedback so it gets included. Sorry: From: Pyun YongHyeon Subject: Re: fun with if_re - Olli -- | 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-stable@FreeBSD.ORG Wed Feb 25 09:47:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E8A1065673; Wed, 25 Feb 2009 09:47:43 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1898FC1B; Wed, 25 Feb 2009 09:47:43 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LcGMf-000L6Y-HO; Wed, 25 Feb 2009 09:47:41 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LcGMf-000Om9-Ey; Wed, 25 Feb 2009 09:47:41 +0000 To: ahmed.aneeth@gmail.com, rwatson@FreeBSD.org In-Reply-To: Message-Id: From: Pete French Date: Wed, 25 Feb 2009 09:47:41 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 09:47:44 -0000 > FYI, I'm currently awaiting testing results from Pete on the MFC of a number > of routing table locking fixes, and once that's merged (hopefully tomorrow?) > I'll start on the patches in the above PR. I've taken a crash-course in > routing table locking in the last few days... :-) Just to let you know that I have had zero crashes since I out the patch live on sunday. Of course thats only three days, but it does look very much like it has fixed it. I am also running with the other routing table patch too.. At this point no news is good news, as it is just sitting there ticking away nicely to itself. I will roll it out to a few more machines over the next few days. But looking good so far, I would encourage other people to try the ptches if they are having problems... -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 11:04:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C34F106564A for ; Wed, 25 Feb 2009 11:04:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E91718FC0C for ; Wed, 25 Feb 2009 11:04:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 892EB46B52; Wed, 25 Feb 2009 06:04:29 -0500 (EST) Date: Wed, 25 Feb 2009 11:04:29 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pete French In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, ahmed.aneeth@gmail.com Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:04:30 -0000 On Wed, 25 Feb 2009, Pete French wrote: >> FYI, I'm currently awaiting testing results from Pete on the MFC of a >> number of routing table locking fixes, and once that's merged (hopefully >> tomorrow?) I'll start on the patches in the above PR. I've taken a >> crash-course in routing table locking in the last few days... :-) > > Just to let you know that I have had zero crashes since I out the patch live > on sunday. Of course thats only three days, but it does look very much like > it has fixed it. I am also running with the other routing table patch too.. > > At this point no news is good news, as it is just sitting there ticking away > nicely to itself. I will roll it out to a few more machines over the next > few days. > > But looking good so far, I would encourage other people to try the ptches if > they are having problems... Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can look at the PR and get that in-progress. Since the code affected by the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly since you've had it in production for a while. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 11:32:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4D21106566C for ; Wed, 25 Feb 2009 11:32:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECB48FC1E for ; Wed, 25 Feb 2009 11:32:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 318A446B59 for ; Wed, 25 Feb 2009 06:32:40 -0500 (EST) Date: Wed, 25 Feb 2009 11:32:40 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Various route locking fixes merged to stable/7 (was: Re: Big problems with 7.1 locking up :-() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:32:41 -0000 Just a minor heads up: I've merged both Kip Macy's lock order fixes to the kernel routing code, and the route locking and reference counting fixes from kern/130652 to stable/7. These fixes should correct a number of reported network-related hangs. We might want to release a subset of these as an errata patch to 7.1 if they shake out well in 7-stable. Thanks again, especially, to Pete for his evaluation of bugs and patches, Kip for his fixes in head, and to Dmitrij Tejblum for his submission of the fixes in the above-mentioned PR. Robert N M Watson Computer Laboratory University of Cambridge On Wed, 25 Feb 2009, Robert Watson wrote: > On Wed, 25 Feb 2009, Pete French wrote: > >>> FYI, I'm currently awaiting testing results from Pete on the MFC of a >>> number of routing table locking fixes, and once that's merged (hopefully >>> tomorrow?) I'll start on the patches in the above PR. I've taken a >>> crash-course in routing table locking in the last few days... :-) >> >> Just to let you know that I have had zero crashes since I out the patch >> live on sunday. Of course thats only three days, but it does look very much >> like it has fixed it. I am also running with the other routing table patch >> too.. >> >> At this point no news is good news, as it is just sitting there ticking >> away nicely to itself. I will roll it out to a few more machines over the >> next few days. >> >> But looking good so far, I would encourage other people to try the ptches >> if they are having problems... > > Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I can > look at the PR and get that in-progress. Since the code affected by the PR > is no longer in 8.x, I'll merge directly to 7.x, and probably fairly quickly > since you've had it in production for a while. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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-stable@FreeBSD.ORG Wed Feb 25 11:55:55 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464CB1065670 for ; Wed, 25 Feb 2009 11:55:55 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f173.google.com (mail-ew0-f173.google.com [209.85.219.173]) by mx1.freebsd.org (Postfix) with ESMTP id CD44A8FC08 for ; Wed, 25 Feb 2009 11:55:54 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy21 with SMTP id 21so736937ewy.19 for ; Wed, 25 Feb 2009 03:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m2tH6K8iCzAIzpLZ1hwJytECflogD36k8hy1kBSgTEE=; b=ogU0zthBFHpZj0+0XpvZV2tLvgNL5nlb+0Cn9hgU8HRfhcvWpM3ml0eRrAFvhSS3Wg GPBtoc8mN+KHK45TEwYGK1cMeHot5jyM385DS/nuFdCoo2B44blNSDRAG6ZhMiAsIHjd AQkn7pLyRgI6eqIOgEWR/QdvO16mQPorxX2s8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fKIXHdQDooAf0BP6zpguNlnygnCLL3Aor/xwhZQ5eU4DlzuYGrcEAJZvK1c9y45Vd0 eRWIBDCxQ0c4kDu3XSBwb0UPKLPZvN8MXuoRobfltU79f9S34j2UkrxZqhPOKEzQiv8M vlHlsZ1+7FB9Zjq1LxlVdVfqqspzFwQE+hcOQ= MIME-Version: 1.0 Received: by 10.210.61.11 with SMTP id j11mr517539eba.186.1235561193943; Wed, 25 Feb 2009 03:26:33 -0800 (PST) In-Reply-To: <003601c9969c$e2cdc310$a8694930$@com> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> Date: Wed, 25 Feb 2009 12:26:33 +0100 Message-ID: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> From: "Paul B. Mahol" To: admin@stardothosting.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 11:55:55 -0000 On 2/24/09, SDH Support wrote: > >> I tried using my ath based D-Link DWL G650, which still seems to have >> some issues in regard to interrupt handling: > > > I've been able to get /most/ wireless cards working with ndiswrapper. *BSD doesnt have ndiswrapper. -- Paul From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 12:13:02 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B5D1065670 for ; Wed, 25 Feb 2009 12:13:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mx1.freebsd.org (Postfix) with ESMTP id 7943F8FC17 for ; Wed, 25 Feb 2009 12:13:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n1PCD0Pv024155; Wed, 25 Feb 2009 12:13:00 GMT (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n1PCCxkA024153; Wed, 25 Feb 2009 12:12:59 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: David Adam In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 25 Feb 2009 12:12:59 +0000 Message-Id: <1235563979.15704.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port Cc: freebsd-stable@FreeBSD.org Subject: Re: 7.1 new install halts on BTX error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:13:03 -0000 On Thu, 2009-01-29 at 12:13 +0900, David Adam wrote: > I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find > that it no longer boots correctly, instead crashing with a BTX backtrace. > If I break to the loader prompt and use 'ls /boot', I also get a > backtrace. > > A new install of 7.1 on this hardware using a separate SCSI card and drive > array also leads to a BTX backtrace. I have copied this below as the first > (most repeatable) error and also included the other problems. > > A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, > also boots fine and will happily list the contents of the original drive's > /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 > install CD also boots and allows me to install over FTP. A patch has just gone into HEAD which may fix this problem. If you want to test it, it's at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.47;r2=1.48 and should apply cleanly. Thanks, Gavin > I have run into BTX problems on this machine before under -CURRENT (see > http://lists.freebsd.org/pipermail/freebsd-current/2008-October/089460.html > ). Dmesg from 7.0 in > http://www.freebsd.org/cgi/query-pr.cgi?prp=125769-1-txt&n=/patch.txt > > A new install of 7.1-RELEASE on separate disks leads to this backtrace: > int=0000000d err=00001840 efl=00010207 eip=00000511 > eax=04551364 ebx=00000000 ecx=00495cae edx=00495cae > esi=00000009 edi=00000001 ebp=00000000 esp=00495cae > cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 > cs:eip=17 00 00 00 00 00 00 0c-00 00 00 00 00 00 00 b9 > ae 5c 49 00 00 00 00 b9-ae 5c 49 00 00 00 00 c8 > ss:esp=43 18 3c 01 74 08 3c 04-0f 85 e4 00 00 00 0f b6 > 43 19 88 86 94 00 00 00-c7 46 30 00 00 00 00 3c > > BTX error on boot with the 7.0 partition that has been upgraded to 7.1: > > int=0000000d err=00000000 efl=00010a92 eip=00000430 > eax=ffffff4c ebx=00006c94 ecx=00000001 edx=00000080 > esi=00000001 edi=ffff9416 ebp=00000000 esp=0008f8b4 > cs=002b ds=0033 es=002b fs=0033 gs=0033 ss=0033 > cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00 > 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > ss:eip=2b 00 00 00 33 00 00 00-00 0c 04 00 5f ad 08 04 > 00 00 00 00 0f 00 00 00-00 00 00 00 24 1c 06 00 > BTX halted > > If I break to the loader prompt and try 'ls /boot', I get this backtrace: > > int=00000006 err=00000000 efl=00010203 eip=00040c08 > eax=000000c6 ebx=00000008 ecx=eb000000 edx=000000c6 > esi=00000004 edi=000000c2 ebp=00000000 esp=0008f8b4 > cs=002b ds=0033 es=002b fs=0033 gs=0033 ss=0033 > cs:eip=8f 49 40 00 94 49 00 cb-00 00 04 00 00 00 fc 07 > 80 00 00 00 04 00 00 00-94 49 00 00 00 00 00 00 > ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > BTX halted > > Any thoughts or suggestions? I will stay on 7.0 for now but have a fairly > large supply of spare drives so I can test new installs if required. > > Thanks, > > David Adam > zanchey@ucc.gu.uwa.edu.au > > _______________________________________________ > 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-stable@FreeBSD.ORG Wed Feb 25 12:28:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C121106566C for ; Wed, 25 Feb 2009 12:28:08 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB748FC08 for ; Wed, 25 Feb 2009 12:28:07 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by fxm12 with SMTP id 12so4679766fxm.19 for ; Wed, 25 Feb 2009 04:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZcRTCB8RrllKLHpUKg9cP9RT7EjymT4a+XzLkblJCZk=; b=ApsOS7bDLICjszvXFWWK82Fr1Jl2BrkRorTsT5IpRGDJBW+1IPNlu8J+9QETE3zqVv ZJ/qIDiPblOUaFztESgS+wWPwyGWILCfjpSeDuBYyLdAxPrDRsufIgorkHgADjBITCR1 5Y13Li81pOc2MNwjtKkv6oGWjZJWiWogVK9/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aiWN7mF8bSiMm0T8Hmq9/d/noHgh/Go/T+mkqCNB5k4U+8rX1XDg9IS/qoJv212ZCU 5UR9lzuHM8EzCyWNr3ncInDUN8Xeml63d0yePyCLH6Aj8gV13XMyf2EUA/d5k2bmd/vB azwLTJafJ/AuBmTkhx0CpNqPQtGx6NnPXYc8o= MIME-Version: 1.0 Received: by 10.103.198.15 with SMTP id a15mr25973muq.60.1235563602452; Wed, 25 Feb 2009 04:06:42 -0800 (PST) In-Reply-To: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> Date: Wed, 25 Feb 2009 09:06:42 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: admin@stardothosting.com, FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:28:08 -0000 On Wed, Feb 25, 2009 at 8:26 AM, Paul B. Mahol wrote: > On 2/24/09, SDH Support wrote: >> >>> I tried using my ath based D-Link DWL G650, which still seems to have >>> some issues in regard to interrupt handling: >> >> >> I've been able to get /most/ wireless cards working with ndiswrapper. > > *BSD doesnt have ndiswrapper. Yes, it does: http://www.freebsd.org/cgi/man.cgi?query=ndis&manpath=FreeBSD+7.1-RELEASE -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 12:39:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989BD1065677 for ; Wed, 25 Feb 2009 12:39:39 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 519A88FC22 for ; Wed, 25 Feb 2009 12:39:39 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so1159yxl.13 for ; Wed, 25 Feb 2009 04:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D/8ILymzTE+yNE6VFPumnqiQAh1sMBIEN7vKxl2xzk0=; b=ka50Dz3p2lXLYIg/5XgvIeqzi9sf1hfv5gnpfgn0jB7vmcNEb8IQH7BGBr1ZGtfhv0 AQh0nPdNUabQjAIkFBeGOvdKc6ajQmCTHSycU9dGdFRUX5YncMUqQIbtg/oIvBkb2D14 bzY+Q0I94tHnctg/F6oYLEmJKf/yja8thtZds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sytzP3xkq8ciM9qsSH8J4p3G3M483YGIlbVZQF6aAbsYXd6abZydfoBD4OA2PMdOd6 9LS9yASwsDgyAhBadfiTEozceTaH2I2m5Trn8uX4+woeOcG1S5tiHb1VdpjMA1eBuj3V 95enz1i1tyxrAVwvqF0nyl4fVrA/fdS29snaw= MIME-Version: 1.0 Received: by 10.231.19.72 with SMTP id z8mr80909iba.42.1235565578435; Wed, 25 Feb 2009 04:39:38 -0800 (PST) In-Reply-To: <003601c9969c$e2cdc310$a8694930$@com> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> Date: Wed, 25 Feb 2009 13:39:38 +0100 Message-ID: <14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com> From: Christian Walther To: admin@stardothosting.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:39:40 -0000 2009/2/24 SDH Support : > >> I tried using my ath based D-Link DWL G650, which still seems to have >> some issues in regard to interrupt handling: > > > I've been able to get /most/ wireless cards working with ndiswrapper. > This is just my personal opinion, and I tend to make scarce use of the word "hate" - but in this case: I really hate ndiswrapper. It might be suitable for some people, but I rather get some piece hardware that is properly supported. Bugs are bad luck, of course, as well as a kernel module author who stops working. But at least I don't have to rely on a windows driver. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 12:41:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226F01065686 for ; Wed, 25 Feb 2009 12:41:11 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id A33E88FC1B for ; Wed, 25 Feb 2009 12:41:10 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by ey-out-2122.google.com with SMTP id d26so359eyd.7 for ; Wed, 25 Feb 2009 04:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1q350qTbmjXM0NK/esbY57KwV4xlpiIZrx99kD/dRfM=; b=BkRZfP3eGASc0/MsP0VcW6M6K03ufoSeqIjx73ADWFh8vjYcuowRXtAVqNJXDbokzX u0q4w94IL+CArT1sb4IbrFy9FTx3KhfFtUYjVX/B0JqL4RSY1KvIlh/BKEFAmdG+JD/5 Nogs03VFNT88eD0waiJAJ/RM8sap8ElJtN8j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=LcVyNM9qgY165d5NcUbHYEUvI4IOjjJe/UmmRxc6mSbxaidgnwVho9M9eZUSsoLz87 6JcMqZQJf7puUwunnd2vNK1VXlNxBq/fqCksy9sxiG4Zxty8h5EA/NdQ6vkb7ux6DQaz SUFBk5HgUkUgvE3MAeGNQXxZds90/SMhSAEjM= MIME-Version: 1.0 Received: by 10.210.16.10 with SMTP id 10mr25709ebp.170.1235564176973; Wed, 25 Feb 2009 04:16:16 -0800 (PST) In-Reply-To: References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> Date: Wed, 25 Feb 2009 12:16:16 +0000 Message-ID: From: Chris Rees To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:41:11 -0000 2009/2/25 Paul B. Mahol : > On 2/24/09, SDH Support wrote: >> >>> I tried using my ath based D-Link DWL G650, which still seems to have >>> some issues in regard to interrupt handling: >> >> >> I've been able to get /most/ wireless cards working with ndiswrapper. > > *BSD doesnt have ndiswrapper. > > > -- > Paul > _______________________________________________ > 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" > Yeah it does... [chris@amnesiac]~% ndisgen =A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 =A0 =A0 =A0------------------ Windows(r) driver converter -------------= ------ =A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 =A0 =A0 =A0This script is designed to guide you through the process =A0 =A0 =A0 =A0of converting a Windows(r) binary driver module and .INF =A0 =A0 =A0 =A0specification file into a FreeBSD ELF kernel module for use =A0 =A0 =A0 =A0with the NDIS compatibility system. =A0 =A0 =A0 =A0The following options are available: =A0 =A0 =A0 =A01] Learn about the NDIS compatibility system =A0 =A0 =A0 =A02] Convert individual firmware files =A0 =A0 =A0 =A03] Convert driver =A0 =A0 =A0 =A04] Exit =A0 =A0 =A0 =A0Enter your selection here and press return: -- R< $&h ! > $- ! $+ =A0 =A0 =A0$@ $2 < @ $1 .UUCP. > (sendmail.cf) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 13:33:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B7DB1065670 for ; Wed, 25 Feb 2009 13:33:27 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-ew0-f173.google.com (mail-ew0-f173.google.com [209.85.219.173]) by mx1.freebsd.org (Postfix) with ESMTP id 97CA18FC0A for ; Wed, 25 Feb 2009 13:33:26 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by ewy21 with SMTP id 21so17895ewy.19 for ; Wed, 25 Feb 2009 05:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Cas/x8gTCHxUCPuDcqoI4c9j30itgfMWNF09MkVGO24=; b=qsjVdHpQ40lh8rb6fLQ+R+j9uqCLw1yKH6H/BYVB3wuH9qHQFhIFNawqe6RkWwNDWk WA7Cc3/kMjofYFMF6b/VKbRz1bDD+ulF+KF8eqsOqevHqw7EmG7iPkcdjCBPTD3PMOMX Or4e1UpWEvHEKFXvBkj/gj/fWgSZ14pckv0+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=WBWsy5RWJaESUNHjyN7H/arNZRjJu358/YFAKhwKizUW5qWXNMVXUnPbfhgeLZDXGx UoQs+LYi3UUQsiPKfL6efFcWeAP4NcQw1zkPpcaaITb+2sJaVNfay0QhNazMDgd0sOtG WYKQ8bydwCe/fpQNKUHBDpRzueRIiLw8Yh+k8= MIME-Version: 1.0 Received: by 10.210.18.18 with SMTP id 18mr97161ebr.71.1235568805627; Wed, 25 Feb 2009 05:33:25 -0800 (PST) In-Reply-To: <14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> <14989d6e0902250439u500da1b2x9967ed48833800ad@mail.gmail.com> Date: Wed, 25 Feb 2009 13:33:25 +0000 Message-ID: From: Chris Rees To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:33:28 -0000 2009/2/25 Christian Walther : > 2009/2/24 SDH Support : >> >>> I tried using my ath based D-Link DWL G650, which still seems to have >>> some issues in regard to interrupt handling: >> >> >> I've been able to get /most/ wireless cards working with ndiswrapper. >> > This is just my personal opinion, and I tend to make scarce use of the > word "hate" - but in this case: I really hate ndiswrapper. > It might be suitable for some people, but I rather get some piece > hardware that is properly supported. Bugs are bad luck, of course, as > well as a kernel module author who stops working. But at least I don't > have to rely on a windows driver. > _______________________________________________ > 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" > True, but ndiswrapper for me was an epiphany of the incredible things free software can do. I found it right back in Debian Woody, where my Ralink card wasn't supported. I got sick of Linux and moved to BSD, where the ral driver was instantly recognised and loaded. -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 13:47:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 200E41065753 for ; Wed, 25 Feb 2009 13:47:23 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id D609E8FC1C for ; Wed, 25 Feb 2009 13:47:22 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from www.lamaiziere.net (unknown [192.168.1.1]) by smtp.lamaiziere.net (Postfix) with ESMTP id 98BD7633301 for ; Wed, 25 Feb 2009 14:47:21 +0100 (CET) Received: from 92.135.105.210 (SquirrelMail authenticated user plfreebsd) by lamaiziere.net with HTTP; Wed, 25 Feb 2009 14:47:21 +0100 (CET) Message-ID: <4958652ce3a9058673b1d72fdc27b569.squirrel@lamaiziere.net> In-Reply-To: <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> Date: Wed, 25 Feb 2009 14:47:21 +0100 (CET) From: "Patrick Lamaiziere" To: "FreeBSD" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:47:23 -0000 > On 2/24/09, SDH Support wrote: >> >>> I tried using my ath based D-Link DWL G650, which still seems to have >>> some issues in regard to interrupt handling: >> >> >> I've been able to get /most/ wireless cards working with ndiswrapper. > > *BSD doesnt have ndiswrapper. There is the ndis driver in FreeBSD. I've used a lot ndis with an Intel 2200 BG card. iwi was not reliable. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 14:36:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B251F106564A for ; Wed, 25 Feb 2009 14:36:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 821738FC0A for ; Wed, 25 Feb 2009 14:36:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id DEB3C46B09; Wed, 25 Feb 2009 09:36:11 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1PEa59N033379; Wed, 25 Feb 2009 09:36:05 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 25 Feb 2009 09:15:57 -0500 User-Agent: KMail/1.9.7 References: <49A46AB4.3080003@palisadesys.com> In-Reply-To: <49A46AB4.3080003@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902250915.57562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Feb 2009 09:36:05 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9047/Wed Feb 25 05:59:41 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Guy Helmer Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 14:36:13 -0000 On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote: > I think I may have found a clue regarding some of the hangs I'm seeing > on FreeBSD 7.1. > I have a program (kvoop), compiled under FreeBSD 6 and using > compatibility libraries under FreeBSD 7, that seems to be consistently > involved during these hangs. This time, I noticed that many processes > are stopped, waiting on the ufs lock. I can't tell for certain, but I > assume this kvoop process 33203 is blocking the other processes. The > kvoop process looks to me like it is waiting for a mutex, but nothing > shows up being deadlocked. Am I on the right track? Is there something > else I should be looking for? > > (kgdb) proc 33203 > [Switching to thread 129 (Thread 100241)]#0 sched_switch ( > td=0xffffff0019109a50, newtd=0x0, flags=1) > at ../../../kern/sched_ule.c:1944 > 1944 cpuid = PCPU_GET(cpuid); > (kgdb) where > #0 sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1) > at ../../../kern/sched_ule.c:1944 > #1 0xffffffff803a573b in mi_switch (flags=1, newtd=0x0) > at ../../../kern/kern_synch.c:440 > #2 0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available. > ) > at ../../../kern/subr_turnstile.c:748 > #3 0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220, > tid=18446742974618442320, opts=Variable "opts" is not available. > ) at ../../../kern/kern_mutex.c:420 > #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, > file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) > at ../../../kern/kern_mutex.c:186 > #5 0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8, > vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40) > at ../../../kern/vfs_cache.c:327 > #6 0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not > available. > ) > at ../../../kern/vfs_cache.c:674 > #7 0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440, > a=0xffffffffa2d936b0) at vnode_if.c:99 > #8 0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57 > #9 0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0) > at ../../../kern/vfs_lookup.c:219 > #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0, > flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600, > fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188 > #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50, > path=0xffffac30
, pathseg=Variable > "pathseg" is not available. > ) > at ../../../kern/vfs_syscalls.c:1032 > #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80) > at ../../../amd64/ia32/ia32_syscall.c:182 > #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65 > #14 0x0000000028284037 in ?? () > > (kgdb) frame 4 > #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, > file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) > at ../../../kern/kern_mutex.c:186 > 186 _get_sleep_lock(m, curthread, opts, file, line); > (kgdb) list > 181 ("mtx_lock() of spin mutex %s @ %s:%d", > m->lock_object.lo_name, > 182 file, line)); > 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER > | LOP_EXCLUSIVE, > 184 file, line); > 185 > 186 _get_sleep_lock(m, curthread, opts, file, line); > 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, > m->mtx_recurse, file, > 188 line); > 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, > file, line); > 190 curthread->td_locks++; > > (kgdb) print *m > $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache", > lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824, > lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600}, > lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0} Is this from a coredump or while the system is live? mtx_lock = 4 indicates the mutex is unlocked, so there shouldn't be any threads waiting on it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 15:02:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A96106567A for ; Wed, 25 Feb 2009 15:02:20 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 055D28FC14 for ; Wed, 25 Feb 2009 15:02:19 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1PF2JOC081656; Wed, 25 Feb 2009 09:02:19 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1PF2JFf078732; Wed, 25 Feb 2009 09:02:19 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49A55D78.1070604@palisadesys.com> Date: Wed, 25 Feb 2009 09:02:16 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Baldwin References: <49A46AB4.3080003@palisadesys.com> <200902250915.57562.jhb@freebsd.org> In-Reply-To: <200902250915.57562.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Wed, 25 Feb 2009 09:02:19 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_48 0.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:02:20 -0000 John Baldwin wrote: > On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote: > >> I think I may have found a clue regarding some of the hangs I'm seeing >> on FreeBSD 7.1. >> I have a program (kvoop), compiled under FreeBSD 6 and using >> compatibility libraries under FreeBSD 7, that seems to be consistently >> involved during these hangs. This time, I noticed that many processes >> are stopped, waiting on the ufs lock. I can't tell for certain, but I >> assume this kvoop process 33203 is blocking the other processes. The >> kvoop process looks to me like it is waiting for a mutex, but nothing >> shows up being deadlocked. Am I on the right track? Is there something >> else I should be looking for? >> >> (kgdb) proc 33203 >> [Switching to thread 129 (Thread 100241)]#0 sched_switch ( >> td=0xffffff0019109a50, newtd=0x0, flags=1) >> at ../../../kern/sched_ule.c:1944 >> 1944 cpuid = PCPU_GET(cpuid); >> (kgdb) where >> #0 sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1) >> at ../../../kern/sched_ule.c:1944 >> #1 0xffffffff803a573b in mi_switch (flags=1, newtd=0x0) >> at ../../../kern/kern_synch.c:440 >> #2 0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available. >> ) >> at ../../../kern/subr_turnstile.c:748 >> #3 0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220, >> tid=18446742974618442320, opts=Variable "opts" is not available. >> ) at ../../../kern/kern_mutex.c:420 >> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, >> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) >> at ../../../kern/kern_mutex.c:186 >> #5 0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8, >> vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40) >> at ../../../kern/vfs_cache.c:327 >> #6 0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not >> available. >> ) >> at ../../../kern/vfs_cache.c:674 >> #7 0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440, >> a=0xffffffffa2d936b0) at vnode_if.c:99 >> #8 0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57 >> #9 0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0) >> at ../../../kern/vfs_lookup.c:219 >> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0, >> flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600, >> fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188 >> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50, >> path=0xffffac30
, pathseg=Variable >> "pathseg" is not available. >> ) >> at ../../../kern/vfs_syscalls.c:1032 >> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80) >> at ../../../amd64/ia32/ia32_syscall.c:182 >> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65 >> #14 0x0000000028284037 in ?? () >> >> (kgdb) frame 4 >> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, >> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) >> at ../../../kern/kern_mutex.c:186 >> 186 _get_sleep_lock(m, curthread, opts, file, line); >> (kgdb) list >> 181 ("mtx_lock() of spin mutex %s @ %s:%d", >> m->lock_object.lo_name, >> 182 file, line)); >> 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER >> | LOP_EXCLUSIVE, >> 184 file, line); >> 185 >> 186 _get_sleep_lock(m, curthread, opts, file, line); >> 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, >> m->mtx_recurse, file, >> 188 line); >> 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, >> file, line); >> 190 curthread->td_locks++; >> >> (kgdb) print *m >> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache", >> lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824, >> lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600}, >> lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0} >> > > Is this from a coredump or while the system is live? mtx_lock = 4 indicates > the mutex is unlocked, so there shouldn't be any threads waiting on it. > > That was from running kgdb on a vmcore file. Would the state of the mutex be different than if I was running kgdb on a live kernel? Thanks, Guy From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 16:45:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF531106566B for ; Wed, 25 Feb 2009 16:45:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 90AF58FC0A for ; Wed, 25 Feb 2009 16:45:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1PGPrgK033183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 08:25:54 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49A57111.3070709@freebsd.org> Date: Wed, 25 Feb 2009 08:25:53 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: utisoft@gmail.com References: <14989d6e0902230721x7a2cd30cw4e548451c87e17cd@mail.gmail.com> <003601c9969c$e2cdc310$a8694930$@com> <3a142e750902250326s20879c29pc89bb9d6e802a4d1@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: FreeBSD Subject: Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 16:45:42 -0000 Chris Rees wrote: > 2009/2/25 Paul B. Mahol : > >> On 2/24/09, SDH Support wrote: >> >>>> I tried using my ath based D-Link DWL G650, which still seems to have >>>> some issues in regard to interrupt handling: >>>> >>> I've been able to get /most/ wireless cards working with ndiswrapper. >>> >> *BSD doesnt have ndiswrapper. >> >> >> -- >> Paul >> _______________________________________________ >> 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" >> >> > > Yeah it does... > > [chris@amnesiac]~% ndisgen > ================================================================== > ------------------ Windows(r) driver converter ------------------- > ================================================================== > > This script is designed to guide you through the process > of converting a Windows(r) binary driver module and .INF > specification file into a FreeBSD ELF kernel module for use > with the NDIS compatibility system. > > The following options are available: > > 1] Learn about the NDIS compatibility system > 2] Convert individual firmware files > 3] Convert driver > 4] Exit > > Enter your selection here and press return: > > "ndiswrapper" refers to the linux version of the Bill Paul's project for freebsd. They are very different; though have the same goal. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 19:05:50 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D481106564A; Wed, 25 Feb 2009 19:05:50 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA5D8FC0A; Wed, 25 Feb 2009 19:05:50 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id A788C334BE; Wed, 25 Feb 2009 20:05:47 +0100 (CET) Date: Wed, 25 Feb 2009 20:05:47 +0100 From: cpghost To: Robert Watson Message-ID: <20090225190546.GA13283@phenom.cordula.ws> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: Big problems with 7.1 locking up :-( X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:05:50 -0000 On Wed, Feb 25, 2009 at 11:04:29AM +0000, Robert Watson wrote: > On Wed, 25 Feb 2009, Pete French wrote: > > >> FYI, I'm currently awaiting testing results from Pete on the MFC of a > >> number of routing table locking fixes, and once that's merged (hopefully > >> tomorrow?) I'll start on the patches in the above PR. I've taken a > >> crash-course in routing table locking in the last few days... :-) > > > > Just to let you know that I have had zero crashes since I out the > > patch live on sunday. Of course thats only three days, but it does > > look very much like it has fixed it. I am also running with the > > other routing table patch too.. At this point no news is good > > news, as it is just sitting there ticking away nicely to itself. I > > will roll it out to a few more machines over the next few days. > > But looking good so far, I would encourage other people to try the > > ptches if they are having problems... > > Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so > that I can look at the PR and get that in-progress. Since the code > affected by the PR is no longer in 8.x, I'll merge directly to 7.x, > and probably fairly quickly since you've had it in production for a > while. Great! I hope this patch will also fix the mysterious hangs I've experienced on Soekris routers since nov/dec 2008. Will try in a few days and report back any further hangs. > Robert N M Watson > Computer Laboratory > University of Cambridge Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 25 22:03:03 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1391065675 for ; Wed, 25 Feb 2009 22:03:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE568FC14 for ; Wed, 25 Feb 2009 22:03:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id BE28C46B7E for ; Wed, 25 Feb 2009 17:03:02 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1PM2ogs036100 for ; Wed, 25 Feb 2009 17:02:56 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 25 Feb 2009 17:02:39 -0500 User-Agent: KMail/1.9.7 References: <200902242311.n1ONBFeF078757@svn.freebsd.org> In-Reply-To: <200902242311.n1ONBFeF078757@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902251702.39725.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 25 Feb 2009 17:02:57 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9047/Wed Feb 25 05:59:41 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Possible fix to BTX boot hangs in 6.4 and 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:03:03 -0000 On Tuesday 24 February 2009 6:11:15 pm John Baldwin wrote: > Author: jhb > Date: Tue Feb 24 23:11:15 2009 > New Revision: 189017 > URL: http://svn.freebsd.org/changeset/base/189017 > > Log: > Fix some more issues with the real mode BTX. > > The old BTX passed the general purpose registers from the 32-bit client to > the routines called via virtual 86 mode. The new BTX did the same thing. > However, it turns out that some instructions behave differently in virtual 86 > mode and real mode (even though this is under-documented). For example, the > LEAVE instruction will cause an exception in real mode if any of the upper > 16-bits of %ebp are non-zero after it executes. In virtual 8086 mode the > upper 16-bits are simply ignored. This could cause faults in hardware > interrupt handlers that inherited an %ebp larger than 0xffff from the 32-bit > client (loader, boot2, etc.) while running in real mode. > > To fix, when executing hardware interrupt handlers provide an explicit clean > state where all the general purpose and segment registers are zero upon > entry to the interrupt handler. While here, I attempted to simplify the > control flow in the 'intusr' code that sets up the various stack frames > and exits protected mode to invoke the requested routine via real mode. > > A huge thanks to Tor Egge (tegge@) for debugging this issue. > > Submitted by: tegge > Reviewed by: tegge > Tested by: bz > MFC after: 1 week This has been confirmed to fix at least some of the boot hangs reported with the BTX changes in 6.4 and 7.1. If you had problems with the new boot code in 6.4 or 7.1 this fix is probably worth trying out. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 00:33:08 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5651065676; Thu, 26 Feb 2009 00:33:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id A1D168FC1F; Thu, 26 Feb 2009 00:33:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id g9so3331089rvb.3 for ; Wed, 25 Feb 2009 16:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8vH6YdP/X62KGje26So0VPPzz1Sdxky1soQ9DfJ9GQM=; b=M+zB1YOzvCNbbtmL6e0ntGQ78jmhZe+CuWVovCGbJDJ91reRp7J6fm+ZodBwDohQ7C W7JEj4okzP5gYJkfTIvd+gfBMwE6YRDHuWAJbCCRELaFqiCwynjbRTzc04ocxDGbOEUx CXJXldc6D+FGGvi+KPlSykbUZK3/mIHoP3dfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GNpC2DVtLbOv9rsLEp0oY8Y7VM4LNRXhduwfOM9PLd1yy3RW0kU+TrSdahhpiU2Q7S bttQQoRwYTSjEDAs+OBMzSs0YUoRaS1nfDs888g7EXbeth7soaeaW7BLV9P84VLN9K5k +iq/MLhtkCOay+zcHEz/SyVhBdWJLPMnNw/Rk= Received: by 10.141.115.20 with SMTP id s20mr282721rvm.285.1235608388183; Wed, 25 Feb 2009 16:33:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm3497629rvb.4.2009.02.25.16.33.05 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:33:07 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 26 Feb 2009 09:38:42 +0900 From: Pyun YongHyeon Date: Thu, 26 Feb 2009 09:38:42 +0900 To: Steve Wills Message-ID: <20090226003842.GB63173@michelle.cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:33:09 -0000 On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > Hi, > > I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > booting, re0 works for only a short time, then gives "re0: PHY read > failed" over and over. Does anyone have a suggestion on how to debug? > I need more information for your hardware revision. Would you show me dmesg output and revision number of if_re.c? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 00:55:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA071065678 for ; Thu, 26 Feb 2009 00:55:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 38B968FC19 for ; Thu, 26 Feb 2009 00:55:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so210358ywt.13 for ; Wed, 25 Feb 2009 16:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8Xt/qm0QuVAOz5ZmjvCOE+O330G01JSCRvwQBYtnpO0=; b=NCfjpyWKCXJxADmDAvdKuYhRP4Bx/IvMLw2qhyTo/u6xbpneRLnkkvAmB89oxiZa+E jNcMZ+NvYLJT7eDwqVWECMvY1UCH7ZGManNp0fdJeHbDxsvQXz3Yi5VvNFyChRwbLiOL 5cpIpXHhOl4j5oTIhy3M6kr9LPRbkkPexRs1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ugpzIx4lVUQtEye1uidxOzn2uPWLpP7G294bHc1Gm0sIesQPIIAjYuJA4/Kl/7bPI+ CPpHkVBEOk2GAurYdNAsHLu+BlKqUjmQF88py8T0Vj9zQpdDopGlvaNimL4h6JMhErs/ b9iv0aTgylIFxAPjs+BDjnhOwG84uFFlAWBXo= Received: by 10.100.172.17 with SMTP id u17mr1070393ane.105.1235609752639; Wed, 25 Feb 2009 16:55:52 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id d38sm12206737and.49.2009.02.25.16.55.48 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:55:50 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 26 Feb 2009 10:01:25 +0900 From: Pyun YongHyeon Date: Thu, 26 Feb 2009 10:01:25 +0900 To: freebsd-stable@freebsd.org Message-ID: <20090226010125.GC63173@michelle.cdnetworks.co.kr> References: <20090204100507.5f223d9e.gerrit@pmp.uni-hannover.de> <20090204104655.GA73543@michelle.cdnetworks.co.kr> <20090205085812.b2deb1f7.gerrit@pmp.uni-hannover.de> <20090205082804.GD77461@michelle.cdnetworks.co.kr> <20090213101910.a126c14d.gerrit@pmp.uni-hannover.de> <20090213102400.GD12653@michelle.cdnetworks.co.kr> <20090213114143.a77f1acb.gerrit@pmp.uni-hannover.de> <20090213113955.GE12653@michelle.cdnetworks.co.kr> <20090223115412.GO79003@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090223115412.GO79003@e-Gitt.NET> User-Agent: Mutt/1.4.2.3i Subject: Re: fun with if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:55:53 -0000 On Mon, Feb 23, 2009 at 12:54:12PM +0100, Oliver Brandmueller wrote: > Hi, > > On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote: > > Ok, try attached patch. > > > Index: sys/dev/re/if_re.c > > =================================================================== > > --- sys/dev/re/if_re.c (revision 187352) > > +++ sys/dev/re/if_re.c (working copy) > > @@ -158,6 +158,8 @@ > > /* Tunables. */ > [...] > > This seems to have fixed a regression I found after the latest re > changes. While the changes lead to a situation, where the re interface > (as opposed to before) seems to always attach, I had the problem that > after 1-2 days it failed (sorry, was just about to investigate when I > tried your patch and thus didn't write down the error message > associated). > > With your patch my re seems to be running fine for the last days now. > That's odd. The patch just revert register mapping method for RTL8169SC family as memory mapped register access seems to have problems on RTL8169SC controllers. From the output below I think your controller is RTL8168C PCIe controller so the patch has no effect on your controller. Would you tell me more details on your issue? CURRENT has more robust code for PCIe based controllers so how about giving it a try on stable/7? Just copying if_re.c/if_rl.c/if_rlreg.h from HEAD to stable/7 should work. > re0@pci0:4:0:0: class=0x020000 card=0x392c1462 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 18 at device 0.0 on pci4 > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:21:85:1e:8b:c9 > re0: [FILTER] > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 01:28:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 094771065673 for ; Thu, 26 Feb 2009 01:28:09 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id B352D8FC20 for ; Thu, 26 Feb 2009 01:28:08 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 19204 invoked by uid 0); 26 Feb 2009 01:28:07 -0000 Received: from unknown (HELO freemac.nat.fasttrackmonkey.com) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Feb 2009 01:28:07 -0000 Date: Wed, 25 Feb 2009 20:28:07 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@freemac.nat.fasttrackmonkey.com To: Robert Watson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Various route locking fixes merged to stable/7 (was: Re: Big problems with 7.1 locking up :-() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:28:09 -0000 On Wed, 25 Feb 2009, Robert Watson wrote: > Just a minor heads up: I've merged both Kip Macy's lock order fixes to the > kernel routing code, and the route locking and reference counting fixes from > kern/130652 to stable/7. These fixes should correct a number of reported > network-related hangs. We might want to release a subset of these as an > errata patch to 7.1 if they shake out well in 7-stable. +1 Charles > Robert N M Watson > Computer Laboratory > University of Cambridge > > On Wed, 25 Feb 2009, Robert Watson wrote: > >> On Wed, 25 Feb 2009, Pete French wrote: >> >>>> FYI, I'm currently awaiting testing results from Pete on the MFC of a >>>> number of routing table locking fixes, and once that's merged (hopefully >>>> tomorrow?) I'll start on the patches in the above PR. I've taken a >>>> crash-course in routing table locking in the last few days... :-) >>> >>> Just to let you know that I have had zero crashes since I out the patch >>> live on sunday. Of course thats only three days, but it does look very >>> much like it has fixed it. I am also running with the other routing table >>> patch too.. >>> >>> At this point no news is good news, as it is just sitting there ticking >>> away nicely to itself. I will roll it out to a few more machines over the >>> next few days. >>> >>> But looking good so far, I would encourage other people to try the ptches >>> if they are having problems... >> >> Thanks -- I've gone ahead and merged the patch to 7.x (r189026) so that I >> can look at the PR and get that in-progress. Since the code affected by >> the PR is no longer in 8.x, I'll merge directly to 7.x, and probably fairly >> quickly since you've had it in production for a while. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> _______________________________________________ >> 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" >> > _______________________________________________ > 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-stable@FreeBSD.ORG Thu Feb 26 02:55:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 378A11065703 for ; Thu, 26 Feb 2009 02:55:56 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0DC8FC18 for ; Thu, 26 Feb 2009 02:55:55 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1Q2trhP028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 13:25:53 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 26 Feb 2009 13:05:41 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4708806.tZeENrZAMp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902261305.50545.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: 7.1 reports serial ports disabled (but they work OK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:55:56 -0000 --nextPart4708806.tZeENrZAMp Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following = in=20 dmesg.. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] However the ports do work fine. I was under the impression that this test was bogus on !i386 and had be=20 removed but I guess I'm wrong :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4708806.tZeENrZAMp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJpf/95ZPcIHs/zowRAltgAJ9RVGbI5+jN1Z+0kp8TowwC0vEmRACfaICK TXVD/BsHPF2lxJEHocQZiCc= =QLDJ -----END PGP SIGNATURE----- --nextPart4708806.tZeENrZAMp-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 03:47:10 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9AB10656C1; Thu, 26 Feb 2009 03:47:10 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from mouf.net (mouf.net [208.86.224.195]) by mx1.freebsd.org (Postfix) with ESMTP id 3F50E8FC19; Thu, 26 Feb 2009 03:47:10 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from [10.0.1.198] (cpe-069-134-142-204.nc.res.rr.com [69.134.142.204]) (authenticated bits=0) by mouf.net (8.14.2/8.14.2) with ESMTP id n1Q3l87q013091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 22:47:09 -0500 (EST) (envelope-from STEVE@stevenwills.com) Message-Id: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> From: Steve Wills To: pyunyh@gmail.com In-Reply-To: <20090226003842.GB63173@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 22:47:07 -0500 References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mouf.net [208.86.224.195]); Wed, 25 Feb 2009 22:47:09 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/9048/Wed Feb 25 16:08:29 2009 on mouf.net X-Virus-Status: Clean Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 03:47:11 -0000 On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > I need more information for your hardware revision. > Would you show me dmesg output and revision number of if_re.c? I assume you only need the re0 related output. If you need the full dmesg, let me know. re0: port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x28000000 re0: MAC rev. 0x00100000 re0: Ethernet address: 00:1f:d0:af:1a:4c re0: [FILTER] re0: link state changed to UP $FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01 yongari Exp $ I get 3 link state DOWN/UP notices when DHCP client starts. It works for exactly 60 seconds after boot, then stops. Patch from earlier "fun with if_re" thread didn't help, if_re.c from -CURRENT failed to build. Reverting back to rev 1.95.2.36.2.2 fixes it. Thanks, Steve From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 04:04:48 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383EE1065676; Thu, 26 Feb 2009 04:04:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id EF25D8FC08; Thu, 26 Feb 2009 04:04:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so337011rvb.43 for ; Wed, 25 Feb 2009 20:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=6oGEm/YtIdFhohKaOPgnT2cBrBLMhIcRD10BL9UHsCI=; b=RP8Ap4UyaPKFa2SrwJaSB/nI5GF2QvE78dZgaOzukNQ4Ixu5+O3iQ200pMQ7IJa5bp 2ih/RGQuipFxH5C+0plamVagca7cJqUaPqVbEzKPzz6hNrvcSkzWH4Aq0/0pKbyokBWs TR2phBrZXHD3TMVyqDMwIxMe4AIwdd/xXewl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Ula4/cmS8pIK/xpo4medvx7wmK4729m58UNXGjhvg2EEsQVwuaeT/ZLGQ/c2M1YBX8 5pUitIsiJ70fW+z8M3C/HZahoHTbCsLhj+7ws1OOaE16Y5ITANmqSUvkF2umfH8SfUTE pSe52sLd8L6MxniArbZlvIs7NbYwabFi6NVtk= Received: by 10.141.96.19 with SMTP id y19mr381343rvl.201.1235621087538; Wed, 25 Feb 2009 20:04:47 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b8sm3711889rvf.8.2009.02.25.20.04.45 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 20:04:46 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 26 Feb 2009 13:10:23 +0900 From: Pyun YongHyeon Date: Thu, 26 Feb 2009 13:10:23 +0900 To: Steve Wills Message-ID: <20090226041023.GD63173@michelle.cdnetworks.co.kr> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:04:48 -0000 On Wed, Feb 25, 2009 at 10:47:07PM -0500, Steve Wills wrote: > On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > >I need more information for your hardware revision. > >Would you show me dmesg output and revision number of if_re.c? > > I assume you only need the re0 related output. If you need the full > dmesg, let me know. > > re0: Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, > 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00100000 > re0: Ethernet address: 00:1f:d0:af:1a:4c > re0: [FILTER] > re0: link state changed to UP > > $FreeBSD: src/sys/dev/re/if_re.c,v 1.95.2.41 2009/02/09 01:38:01 > yongari Exp $ > > I get 3 link state DOWN/UP notices when DHCP client starts. It works That's normal(Technically this is not correct behavior but it's the way how it was implemented in driver). > for exactly 60 seconds after boot, then stops. I guess re(4) thinks it lost established link. How about unplug and then replug UTP cable? Would you show me "devinfo -rv | grep phy"? > Patch from earlier "fun > with if_re" thread didn't help, Your issue is completely different one. > if_re.c from -CURRENT failed to build. You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to build it on stable. > Reverting back to rev 1.95.2.36.2.2 fixes it. > Your controller looks like RTL8168D PCIe controller. ATM I have no idea why if_re.c 1.95.2.41 does not work. I'll let you know if I find a clue. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 04:15:41 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5501065670; Thu, 26 Feb 2009 04:15:41 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from mouf.net (mouf.net [208.86.224.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8F39F8FC1B; Thu, 26 Feb 2009 04:15:41 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from [10.0.1.198] (cpe-069-134-142-204.nc.res.rr.com [69.134.142.204]) (authenticated bits=0) by mouf.net (8.14.2/8.14.2) with ESMTP id n1Q4FePd018604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 23:15:40 -0500 (EST) (envelope-from STEVE@stevenwills.com) Message-Id: <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com> From: Steve Wills To: pyunyh@gmail.com In-Reply-To: <20090226041023.GD63173@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 23:15:38 -0500 References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> <20090226041023.GD63173@michelle.cdnetworks.co.kr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mouf.net [208.86.224.195]); Wed, 25 Feb 2009 23:15:41 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/9048/Wed Feb 25 16:08:29 2009 on mouf.net X-Virus-Status: Clean Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:15:42 -0000 On Feb 25, 2009, at 11:10 PM, Pyun YongHyeon wrote: >> I get 3 link state DOWN/UP notices when DHCP client starts. It works > > That's normal(Technically this is not correct behavior but it's the > way how it was implemented in driver). Ok. Not a huge deal, but would be nice to fix, of course. >> for exactly 60 seconds after boot, then stops. > > I guess re(4) thinks it lost established link. How about unplug and > then replug UTP cable? Would you show me "devinfo -rv | grep phy"? rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 >> Patch from earlier "fun >> with if_re" thread didn't help, > > Your issue is completely different one. Ok, good to know. >> if_re.c from -CURRENT failed to build. > > You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to > build it on stable. Ok. I can test that if you wish. >> Reverting back to rev 1.95.2.36.2.2 fixes it. >> > > Your controller looks like RTL8168D PCIe controller. ATM I have no > idea why if_re.c 1.95.2.41 does not work. I'll let you know if I > find a clue. Ok. I'm happy to test any patches. Thanks, Steve From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 04:21:57 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B08F106567D; Thu, 26 Feb 2009 04:21:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id D67C68FC17; Thu, 26 Feb 2009 04:21:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so343233rvb.43 for ; Wed, 25 Feb 2009 20:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=hZbNxsX4k5mlC/WLuVfZmhBb1ur64Issx/paO07u2Q4=; b=pAZHgYub9GkUIrhaWlqeebJoRkHDa3HMJJLgQlhztFCwq+KzJPdmkAyykKEgy7KZ14 awa9kLKW7h69X31u8QtUWr3Jb0gd343cmnjAXjYRb9eUg+dRVXbKj0g33CZvK5R+9wkY 4Hg42vrZTsWqJ72TMU1rmWdU0osCyplWyK9dg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=c1VSA7zneW3yuNKvGPybmiKMLwTiIZNB1L9nNVwagSdStvRHOYpbJUUbBVhaSYaY/l 3Ee96hwSOqh8obsNVJOgOJS/cIZ6v5+ooAWL/DNKO1g1fK5vd7u4AoSMSfm10nBPMKKE PGpEjlfY9ISoj2bf2+izd8peaJqsmeRICUFJA= Received: by 10.141.115.6 with SMTP id s6mr397430rvm.117.1235622116432; Wed, 25 Feb 2009 20:21:56 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k2sm3924027rvb.4.2009.02.25.20.21.54 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 20:21:55 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 26 Feb 2009 13:27:32 +0900 From: Pyun YongHyeon Date: Thu, 26 Feb 2009 13:27:32 +0900 To: Steve Wills Message-ID: <20090226042732.GE63173@michelle.cdnetworks.co.kr> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> <20090226041023.GD63173@michelle.cdnetworks.co.kr> <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:21:59 -0000 On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote: [...] > >I guess re(4) thinks it lost established link. How about unplug and > >then replug UTP cable? Would you show me "devinfo -rv | grep phy"? > > rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 > And unpluging/repluging didn't help? > >You have to use if_re.c/if_rl.c and if_rlreg.h from CURRENT to > >build it on stable. > > Ok. I can test that if you wish. > I guess re(4) in CURRENT may not help as rev 1.95.2.41 still has issues on your controller. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 04:32:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34198106566B for ; Thu, 26 Feb 2009 04:32:33 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from smtp12.dentaku.gol.com (smtp12.dentaku.gol.com [203.216.5.74]) by mx1.freebsd.org (Postfix) with ESMTP id 074728FC12 for ; Thu, 26 Feb 2009 04:32:32 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[172.16.1.151]) by smtp12.dentaku.gol.com with esmtpsa (Dentaku) id 1LcXjh-00048c-4B for ; Thu, 26 Feb 2009 13:20:37 +0900 Message-ID: <49A61894.5040804@fusiongol.com> Date: Thu, 26 Feb 2009 13:20:36 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com Subject: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:32:33 -0000 I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 Typically, It works for a while until eventually it stalls data transfers completely. It always seems to do this after an unspecified amount of time. I know the hardware isn't at fault because the device works fine under Linux. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 05:16:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD0A41065676 for ; Thu, 26 Feb 2009 05:16:01 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id A939F8FC14 for ; Thu, 26 Feb 2009 05:16:01 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so363649rvb.43 for ; Wed, 25 Feb 2009 21:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem; bh=2BjFsGOcClLbDpminraSYwA802cpxMn/FqgGdcxYSeU=; b=C0pFg5aP6BnPyG/3ku8TGKUGsgEgsmCdbTMwBAUPqpGrFTnK+tLF14f3HoLi1HmGXr wt20mJGhMbn1+qV4XMn1iTLkehEHuSNj0NWoSQBrHRtYpUOg2Nf1rEcNALMQYJlJ+K1c vzrW+A0dDs/F83gW+930sWNlGSIyn4K5I7C2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :organization:x-operation-sytem; b=cpVSaX6GhqHDCRq0EAKGo1Mv4+3mx94s/kiHTlWr1Z1F5BtAtJgx+YHoqxbGr7BKKs h/1I6mYw9RFyGMpM8r/w/MPU+h3jX7O/M7NkrgVo2Fb2gw1LgT5XYKDWP5bHE61UErlq 5P1n/sH5eN0FcnmWznKY+hMpzrmLOY8Du2oa4= Received: by 10.140.186.20 with SMTP id j20mr401870rvf.230.1235624047851; Wed, 25 Feb 2009 20:54:07 -0800 (PST) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id b39sm1827245rvf.9.2009.02.25.20.54.05 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 20:54:07 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Thu, 26 Feb 2009 13:53:40 +0900 From: Weongyo Jeong Date: Thu, 26 Feb 2009 13:53:40 +0900 To: Nathan Butcher Message-ID: <20090226045340.GC70144@weongyo.cdnetworks.kr> References: <49A61894.5040804@fusiongol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A61894.5040804@fusiongol.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-stable@freebsd.org Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 05:16:02 -0000 On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: > I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. > It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 > > Typically, It works for a while until eventually it stalls data > transfers completely. It always seems to do this after an unspecified > amount of time. > > I know the hardware isn't at fault because the device works fine under > Linux. Could you please check that `ifconfig -bgscan' disabling the background scan helps your symptom? regards, Weongyo Jeong From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 05:22:08 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23EF91065696; Thu, 26 Feb 2009 05:22:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id D3D038FC0A; Thu, 26 Feb 2009 05:22:07 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-64-197-185.hsd1.ms.comcast.net [75.64.197.185]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id A2D8437B5BD; Wed, 25 Feb 2009 23:06:46 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 6C74F61C44; Wed, 25 Feb 2009 23:06:45 -0600 (CST) Date: Wed, 25 Feb 2009 23:06:45 -0600 From: "Matthew D. Fuller" To: Steve Wills Message-ID: <20090226050645.GS19899@over-yonder.net> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.18-fullermd.4 (2008-05-17) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on thyme.infocus-llc.com X-Virus-Status: Clean Cc: pyunyh@gmail.com, stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 05:22:13 -0000 On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of Steve Wills, and lo! it spake thus: > > re0: Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, > 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00100000 For a data point, I have re0: port 0xdc00-0xdcff mem 0xfdfff000-0xfdffffff irq 19 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK. I have gotten a few Tx interrupt watchdog timeouts, which I don't recall seeing in any quantity before, but they don't seem to cause any problems. It was previously on a ~Dec 2007 RELENG_7 and worked fine there (and had MSI enabled, as well). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 05:36:52 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 843781065670; Thu, 26 Feb 2009 05:36:52 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from mouf.net (mouf.net [208.86.224.195]) by mx1.freebsd.org (Postfix) with ESMTP id 42C5B8FC0C; Thu, 26 Feb 2009 05:36:51 +0000 (UTC) (envelope-from STEVE@stevenwills.com) Received: from [10.0.1.198] (cpe-069-134-142-204.nc.res.rr.com [69.134.142.204]) (authenticated bits=0) by mouf.net (8.14.2/8.14.2) with ESMTP id n1Q5aoFo056733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Feb 2009 00:36:51 -0500 (EST) (envelope-from STEVE@stevenwills.com) Message-Id: <22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com> From: Steve Wills To: pyunyh@gmail.com In-Reply-To: <20090226042732.GE63173@michelle.cdnetworks.co.kr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 00:36:48 -0500 References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> <20090226041023.GD63173@michelle.cdnetworks.co.kr> <594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com> <20090226042732.GE63173@michelle.cdnetworks.co.kr> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mouf.net [208.86.224.195]); Thu, 26 Feb 2009 00:36:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/9048/Wed Feb 25 16:08:29 2009 on mouf.net X-Virus-Status: Clean Cc: stable@freebsd.org, yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 05:36:52 -0000 On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote: > On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote: > > [...] >>> I guess re(4) thinks it lost established link. How about unplug and >>> then replug UTP cable? Would you show me "devinfo -rv | grep phy"? >> >> rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1 >> > > And unpluging/repluging didn't help? No, didn't help. Steve From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 05:59:21 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D526106566B for ; Thu, 26 Feb 2009 05:59:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id B6C7A8FC18 for ; Thu, 26 Feb 2009 05:59:20 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n1Q5xJ9E053201; Thu, 26 Feb 2009 16:59:19 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 26 Feb 2009 16:59:18 +1100 (EST) From: Ian Smith To: "Daniel O'Connor" In-Reply-To: <200902261305.50545.doconnor@gsoft.com.au> Message-ID: <20090226165128.M71460@sola.nimnet.asn.au> References: <200902261305.50545.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 reports serial ports disabled (but they work OK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 05:59:21 -0000 On Thu, 26 Feb 2009, Daniel O'Connor wrote: > I have an amd64 7.1 install on a SuperMicro C2SBA+ and I see the following in > dmesg.. > > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > > However the ports do work fine. The last 3 lines of each show success, despite earlier prevarication. > I was under the impression that this test was bogus on !i386 and had be > removed but I guess I'm wrong :) As long as they work! cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 06:34:46 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBD6106566B for ; Thu, 26 Feb 2009 06:34:46 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 312038FC1C for ; Thu, 26 Feb 2009 06:34:45 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1Q6Yifv037742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 17:04:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Ian Smith Date: Thu, 26 Feb 2009 16:57:35 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <200902261305.50545.doconnor@gsoft.com.au> <20090226165128.M71460@sola.nimnet.asn.au> In-Reply-To: <20090226165128.M71460@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1372500.rxRZ8cVKHl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902261657.43703.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 reports serial ports disabled (but they work OK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 06:34:47 -0000 --nextPart1372500.rxRZ8cVKHl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 26 February 2009 16:29:18 Ian Smith wrote: > > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > > sio1: type 16550A > > sio1: [FILTER] > > > > However the ports do work fine. > > The last 3 lines of each show success, despite earlier prevarication. Yes, but the implication is that they might not work :) > > I was under the impression that this test was bogus on !i386 and had be > > removed but I guess I'm wrong :) > > As long as they work! Yeah, makes for annoying questions by end users though. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1372500.rxRZ8cVKHl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJpjZY5ZPcIHs/zowRAircAJ9jVi5G42mBDxGZN613BcffhYM1IgCdH2qd qVSVDtruCnQDDlDBjd9Jno8= =itXw -----END PGP SIGNATURE----- --nextPart1372500.rxRZ8cVKHl-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 07:50:06 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E42106566B; Thu, 26 Feb 2009 07:50:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id D8E538FC12; Thu, 26 Feb 2009 07:50:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so421239rvb.43 for ; Wed, 25 Feb 2009 23:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=STXYA/FyEBtpjZlVgkKG6MPtqHcg0EhQluGMZ10l/9U=; b=pTzdYe+UjJ5EpqlBAJH1s4Qqx9Ly4FhFSENzQ1nayh8NioyxFYlXBo5HGKRZMK/zOU IYx7oWrGS2syQFx7EORzY7FHwdxO0MkknTAnT5bQ7u09ZpyiX09SW/pv/a753Kj3XnM1 9RFBo/Zv/cVbxqeM4P1THiUi9og8cNcUMa9KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=gajiHZvUZjTKKtkcTSeqSh5mYEiZwRYfsrsB+4z8W7cVOqZ3A26m+sfz84JOKlvEdG KL7BHjy+BqOyMCLsQXbPerYvTj8zfOGiS+FE4rGhjZQBTDa1Ie6nRGrVpuVaem0J7qSm yx8BVEa4XK5brlFkku5jRPXfuOvT3gk0IgQEY= Received: by 10.141.115.6 with SMTP id s6mr493157rvm.186.1235634605546; Wed, 25 Feb 2009 23:50:05 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id f42sm330449rvb.3.2009.02.25.23.50.03 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 23:50:04 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 26 Feb 2009 16:55:43 +0900 From: Pyun YongHyeon Date: Thu, 26 Feb 2009 16:55:43 +0900 To: "Matthew D. Fuller" Message-ID: <20090226075543.GF63173@michelle.cdnetworks.co.kr> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com> <20090226050645.GS19899@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090226050645.GS19899@over-yonder.net> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, Steve Wills , yongari@freebsd.org Subject: Re: 7.1-R to RELENG_7 upgrade breaks re nic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 07:50:07 -0000 On Wed, Feb 25, 2009 at 11:06:45PM -0600, Matthew D. Fuller wrote: > On Wed, Feb 25, 2009 at 10:47:07PM -0500 I heard the voice of > Steve Wills, and lo! it spake thus: > > > > re0: > Gigabit Ethernet> port 0x7e00-0x7eff mem 0xfd3ff000-0xfd3fffff, > > 0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 > > re0: Chip rev. 0x28000000 > > re0: MAC rev. 0x00100000 > > For a data point, I have > > re0: Gigabit Ethernet> port 0xdc00-0xdcff mem 0xfdfff000-0xfdffffff > irq 19 at device 0.0 on pci2 > re0: turning off MSI enable bit. > re0: Chip rev. 0x38000000 > re0: MAC rev. 0x00000000 > > on a recent 7-STABLE (if_re.c,v 1.95.2.41) which is working OK. I > have gotten a few Tx interrupt watchdog timeouts, which I don't recall > seeing in any quantity before, but they don't seem to cause any If the watchdog timeout message contains "missed Tx interrupts" you can safely ignore them. It's not real watchdog timeouts. > problems. It was previously on a ~Dec 2007 RELENG_7 and worked fine > there (and had MSI enabled, as well). > Try re(4) in HEAD. You may not see watchdog timeouts anymore. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 08:43:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1866D106564A for ; Thu, 26 Feb 2009 08:43:02 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:250:4ff:fe43:9d15]) by mx1.freebsd.org (Postfix) with ESMTP id 848DA8FC14 for ; Thu, 26 Feb 2009 08:43:01 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (trond@localhost [127.0.0.1]) by ramstind.fig.ol.no (8.13.8/8.13.8) with ESMTP id n1Q8gtnA043780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2009 09:42:56 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by ramstind.fig.ol.no (8.13.8/8.13.8/Submit) with ESMTP id n1Q8gtrp043777 for ; Thu, 26 Feb 2009 09:42:55 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: ramstind.fig.ol.no: trond owned process doing -bs Date: Thu, 26 Feb 2009 09:42:55 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable Message-ID: <20090226093219.R21334@ramstind.fig.ol.no> Organization: =?ISO-8859-1?Q?Fagskolen_i_Gj=F8vik?= OpenPGP: url=http://fagskolen.gjovik.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-788785374-1235637775=:21334" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=failed X-Spam-Checker-Version: SpamAssassin on ramstind.fig.ol.no Subject: What startup script is supposed to handle ipv6_defaultrouter="..."? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:43:02 -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-788785374-1235637775=:21334 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On a system running 7.1-STABLE as of early February, cvsup'd with tag=RELENG_7 just prior to recompiling the system, setting ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect. I'm forced to set the IPv6 gateway using commands outside the regular startup scripts. The command grep ipv6_defaultrouter /etc/rc.d/* doesn't give anything useful, either. I guess /etc/rc.d/network_ipv6 is missing the required code. Here's the revision string from my /etc/rc.d/network_ipv6: # $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $ Is this the correct revision number for tag=RELENG_7? -- ---------------------------------------------------------------------- Trond Endrestøl | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64 --0-788785374-1235637775=:21334-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 09:40:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ECF0106564A for ; Thu, 26 Feb 2009 09:40:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1699C8FC15 for ; Thu, 26 Feb 2009 09:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 413F941C6B4; Thu, 26 Feb 2009 10:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id JuhHuPseU69G; Thu, 26 Feb 2009 10:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E01F041C6A7; Thu, 26 Feb 2009 10:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A1B7E4448E6; Thu, 26 Feb 2009 09:37:21 +0000 (UTC) Date: Thu, 26 Feb 2009 09:37:21 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: =?ISO-8859-1?Q?Trond_Endrest=F8l?= In-Reply-To: <20090226093219.R21334@ramstind.fig.ol.no> Message-ID: <20090226093623.J53478@maildrop.int.zabbadoz.net> References: <20090226093219.R21334@ramstind.fig.ol.no> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1642179465-1235641041=:53478" Cc: FreeBSD stable Subject: Re: What startup script is supposed to handle ipv6_defaultrouter="..."? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:40:08 -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-1642179465-1235641041=:53478 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 26 Feb 2009, Trond Endrest=F8l wrote: > On a system running 7.1-STABLE as of early February, cvsup'd with > tag=3DRELENG_7 just prior to recompiling the system, setting > ipv6_defaultrouter=3D"..." in /etc/rc.conf seems to have no effect. > I'm forced to set the IPv6 gateway using commands outside the regular > startup scripts. > > The command > > grep ipv6_defaultrouter /etc/rc.d/* > > doesn't give anything useful, either. > > I guess /etc/rc.d/network_ipv6 is missing the required code. I guess it's in /etc/network.subr Did you se ipv6_enable=3D"YES" in rc.conf as well? /bz --=20 Bjoern A. Zeeb The greatest risk is not taking one. --0-1642179465-1235641041=:53478-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 10:01:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B188C1065678 for ; Thu, 26 Feb 2009 10:01:43 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (pop3.fagskolen.gjovik.no [IPv6:2001:700:1100:1:250:4ff:fe43:9d15]) by mx1.freebsd.org (Postfix) with ESMTP id 214E78FC1E for ; Thu, 26 Feb 2009 10:01:42 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (trond@localhost [127.0.0.1]) by ramstind.fig.ol.no (8.13.8/8.13.8) with ESMTP id n1QA1b25045437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2009 11:01:37 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by ramstind.fig.ol.no (8.13.8/8.13.8/Submit) with ESMTP id n1QA1bsX045434 for ; Thu, 26 Feb 2009 11:01:37 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: ramstind.fig.ol.no: trond owned process doing -bs Date: Thu, 26 Feb 2009 11:01:36 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable In-Reply-To: <20090226093219.R21334@ramstind.fig.ol.no> Message-ID: <20090226105039.L45052@ramstind.fig.ol.no> References: <20090226093219.R21334@ramstind.fig.ol.no> Organization: =?ISO-8859-1?Q?Fagskolen_i_Gj=F8vik?= OpenPGP: url=http://fagskolen.gjovik.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-788785374-1235637775=:21334" Content-ID: <20090226105039.M45052@ramstind.fig.ol.no> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=failed X-Spam-Checker-Version: SpamAssassin on ramstind.fig.ol.no Subject: Re: What startup script is supposed to handle ipv6_defaultrouter="..."? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:01:44 -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-788785374-1235637775=:21334 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20090226105039.C45052@ramstind.fig.ol.no> On Thu, 26 Feb 2009 09:42+0100, Trond Endrestøl wrote: > On a system running 7.1-STABLE as of early February, cvsup'd with > tag=RELENG_7 just prior to recompiling the system, setting > ipv6_defaultrouter="..." in /etc/rc.conf seems to have no effect. > I'm forced to set the IPv6 gateway using commands outside the regular > startup scripts. For the record, here are the IPv6 related variables found in this particular system's /etc/rc.conf file: ipv6_enable="YES" ipv6_defaultrouter="2001:700:XXXX:YYYY::1" ipv6_ifconfig_em0="2001:700:XXXX:YYYY::24 prefixlen 64" If I leave out the static address assignment on em0 and the static router address, the system gets both an autoconfigurated IPv6 address as well as receiving the router's link local IPv6 address and the system will use that LL address as the default router. I'm merely interested in giving em0 a static IPv6 address, and if possible leave everything else to be determined by the router's advertisement. Do I need to fiddle with one or more sysctl variables? -- ---------------------------------------------------------------------- Trond Endrestøl | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64 --0-788785374-1235637775=:21334-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 12:19:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12384106566C for ; Thu, 26 Feb 2009 12:19:25 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (mail.fagskolen.gjovik.no [IPv6:2001:700:1100:1:250:4ff:fe43:9d15]) by mx1.freebsd.org (Postfix) with ESMTP id 78FFE8FC17 for ; Thu, 26 Feb 2009 12:19:24 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from ramstind.fig.ol.no (trond@localhost [127.0.0.1]) by ramstind.fig.ol.no (8.13.8/8.13.8) with ESMTP id n1QCJJfe047700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2009 13:19:19 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by ramstind.fig.ol.no (8.13.8/8.13.8/Submit) with ESMTP id n1QCJIgl047697 for ; Thu, 26 Feb 2009 13:19:18 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: ramstind.fig.ol.no: trond owned process doing -bs Date: Thu, 26 Feb 2009 13:19:18 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable In-Reply-To: <20090226105039.L45052@ramstind.fig.ol.no> Message-ID: <20090226131701.F45052@ramstind.fig.ol.no> References: <20090226093219.R21334@ramstind.fig.ol.no> <20090226105039.L45052@ramstind.fig.ol.no> Organization: =?ISO-8859-1?Q?Fagskolen_i_Gj=F8vik?= OpenPGP: url=http://fagskolen.gjovik.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-788785374-1235637775=:21334" Content-ID: <20090226105039.M45052@ramstind.fig.ol.no> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=failed X-Spam-Checker-Version: SpamAssassin on ramstind.fig.ol.no Subject: Re: What startup script is supposed to handle ipv6_defaultrouter="..."? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:19:25 -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-788785374-1235637775=:21334 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20090226105039.C45052@ramstind.fig.ol.no> Sorry about the noise. Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 showed no default route even when it was supposed to. And yes, I did reboot the system to verify my settings. Again, my bad. -- ---------------------------------------------------------------------- Trond Endrestøl | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64 --0-788785374-1235637775=:21334-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 14:18:01 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991E6106566B for ; Thu, 26 Feb 2009 14:18:01 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) by mx1.freebsd.org (Postfix) with ESMTP id 1012F8FC14 for ; Thu, 26 Feb 2009 14:18:00 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyxys.ka.sub.org [IPv6:2001:5c0:8521:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.2/8.14.2) with ESMTP id n1QDpm6C008226 for ; Thu, 26 Feb 2009 14:51:49 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.3/8.14.3) with ESMTP id n1QDpl04038892 for ; Thu, 26 Feb 2009 14:51:47 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.3/8.14.3/Submit) id n1QDpitc038891 for freebsd-stable@freebsd.org; Thu, 26 Feb 2009 14:51:44 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Thu, 26 Feb 2009 14:51:43 +0100 From: Wolfgang Zenker To: FreeBSD stable Message-ID: <20090226135143.GA38688@lyxys.ka.sub.org> References: <20090226093219.R21334@ramstind.fig.ol.no> <20090226105039.L45052@ramstind.fig.ol.no> <20090226131701.F45052@ramstind.fig.ol.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090226131701.F45052@ramstind.fig.ol.no> User-Agent: Mutt/1.4.2.3i Organization: private site Subject: Re: What startup script is supposed to handle ipv6_defaultrouter="..."? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 14:18:01 -0000 Hi, * Trond Endrestøl [090226 13:19]: > Sorry about the noise. > Maybe I wasn't too patient, but I will swear that netstat -rnf inet6 > showed no default route even when it was supposed to. And yes, I did > reboot the system to verify my settings. > Again, my bad. I have the problem sometimes that the system tries to get IPv6 router advertisments before the interface is up. In this case it doesn't retry, at least not within the time frame I was patient enough to wait. In this case I usually call rtsol by hand to get the parameters. Wolfgang From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 15:25:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 952421065672 for ; Thu, 26 Feb 2009 15:25:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57CC88FC0A for ; Thu, 26 Feb 2009 15:25:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id CBD0346B45; Thu, 26 Feb 2009 10:25:53 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1QFPOR1042853; Thu, 26 Feb 2009 10:25:47 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 26 Feb 2009 10:12:24 -0500 User-Agent: KMail/1.9.7 References: <49A46AB4.3080003@palisadesys.com> <200902250915.57562.jhb@freebsd.org> <49A55D78.1070604@palisadesys.com> In-Reply-To: <49A55D78.1070604@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902261012.24325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Feb 2009 10:25:47 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9051/Thu Feb 26 08:08:01 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Guy Helmer Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:25:54 -0000 On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote: > John Baldwin wrote: > > On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote: > > > >> I think I may have found a clue regarding some of the hangs I'm seeing > >> on FreeBSD 7.1. > >> I have a program (kvoop), compiled under FreeBSD 6 and using > >> compatibility libraries under FreeBSD 7, that seems to be consistently > >> involved during these hangs. This time, I noticed that many processes > >> are stopped, waiting on the ufs lock. I can't tell for certain, but I > >> assume this kvoop process 33203 is blocking the other processes. The > >> kvoop process looks to me like it is waiting for a mutex, but nothing > >> shows up being deadlocked. Am I on the right track? Is there something > >> else I should be looking for? > >> > >> (kgdb) proc 33203 > >> [Switching to thread 129 (Thread 100241)]#0 sched_switch ( > >> td=0xffffff0019109a50, newtd=0x0, flags=1) > >> at ../../../kern/sched_ule.c:1944 > >> 1944 cpuid = PCPU_GET(cpuid); > >> (kgdb) where > >> #0 sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1) > >> at ../../../kern/sched_ule.c:1944 > >> #1 0xffffffff803a573b in mi_switch (flags=1, newtd=0x0) > >> at ../../../kern/kern_synch.c:440 > >> #2 0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available. > >> ) > >> at ../../../kern/subr_turnstile.c:748 > >> #3 0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220, > >> tid=18446742974618442320, opts=Variable "opts" is not available. > >> ) at ../../../kern/kern_mutex.c:420 > >> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, > >> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) > >> at ../../../kern/kern_mutex.c:186 > >> #5 0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8, > >> vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40) > >> at ../../../kern/vfs_cache.c:327 > >> #6 0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not > >> available. > >> ) > >> at ../../../kern/vfs_cache.c:674 > >> #7 0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440, > >> a=0xffffffffa2d936b0) at vnode_if.c:99 > >> #8 0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57 > >> #9 0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0) > >> at ../../../kern/vfs_lookup.c:219 > >> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0, > >> flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600, > >> fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188 > >> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50, > >> path=0xffffac30
, pathseg=Variable > >> "pathseg" is not available. > >> ) > >> at ../../../kern/vfs_syscalls.c:1032 > >> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80) > >> at ../../../amd64/ia32/ia32_syscall.c:182 > >> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65 > >> #14 0x0000000028284037 in ?? () > >> > >> (kgdb) frame 4 > >> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, > >> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) > >> at ../../../kern/kern_mutex.c:186 > >> 186 _get_sleep_lock(m, curthread, opts, file, line); > >> (kgdb) list > >> 181 ("mtx_lock() of spin mutex %s @ %s:%d", > >> m->lock_object.lo_name, > >> 182 file, line)); > >> 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER > >> | LOP_EXCLUSIVE, > >> 184 file, line); > >> 185 > >> 186 _get_sleep_lock(m, curthread, opts, file, line); > >> 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, > >> m->mtx_recurse, file, > >> 188 line); > >> 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, > >> file, line); > >> 190 curthread->td_locks++; > >> > >> (kgdb) print *m > >> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache", > >> lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824, > >> lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600}, > >> lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0} > >> > > > > Is this from a coredump or while the system is live? mtx_lock = 4 indicates > > the mutex is unlocked, so there shouldn't be any threads waiting on it. > > > > > That was from running kgdb on a vmcore file. Would the state of the > mutex be different than if I was running kgdb on a live kernel? Well, if it was live perhaps the thread wasn't hung but was changing states while you were watching it. However, that is not true in a coredump. This is a very disturbing bug as it means something is broken in the mutex implementation itself. Have you reproduced this on multiple machines? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 16:14:13 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 246901065675 for ; Thu, 26 Feb 2009 16:14:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 396E28FC28 for ; Thu, 26 Feb 2009 16:14:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06124 for ; Thu, 26 Feb 2009 18:14:10 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49A6BFD1.6090601@icyb.net.ua> Date: Thu, 26 Feb 2009 18:14:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: qemu+aio vs C2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:14:13 -0000 I see something unusual and surprising for me: if I kldload aio for qemu's sake and then actually start qemu, I see that share of C2 in cx_usage is constantly dropping and then finally there is "too many short sleeps, backing off to C1". This is on i386 with stable/7 as of r188116. I am out of ideas. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 16:27:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BB291065673 for ; Thu, 26 Feb 2009 16:27:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id D2EFB8FC1E for ; Thu, 26 Feb 2009 16:27:25 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm2 with SMTP id 2so588820fxm.43 for ; Thu, 26 Feb 2009 08:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qYXrTulLPRh2lrY3uNGWQr2qLXMPWHW8/+974Zxc9gQ=; b=D6swoBIAR5vq7Hf8r6L31yHE6wTb2eRLmsYKak70gRln3sm9kwxk5Wtp3MCT0haYFS bxTWNU4mhrHWrPmeYurdoTFo9ieifLg83wEkBxFyPQwGu3z2dx574w6LZBVJDM+Ej++e zj+yYv0HEi/JToCKx2hlMXZ5atpKdz7C21FF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VeKNE+DueGcIVXR3Eqo85PE60iBjV2WnhVDyP7S81QjEuo4st9zWwXrDiKhHwv4VIi M+Y7JDGc3vo618nfj/cazj4R7mrcNulJjxG2u2QBmBeaXUIapgxi0goP6uDgx716Bt7I ta9VEOPx62LwO+8VyDFGoPXzC1uLp9g33rFXM= MIME-Version: 1.0 Received: by 10.223.113.136 with SMTP id a8mr2257548faq.76.1235665644766; Thu, 26 Feb 2009 08:27:24 -0800 (PST) In-Reply-To: <49A6BFD1.6090601@icyb.net.ua> References: <49A6BFD1.6090601@icyb.net.ua> Date: Thu, 26 Feb 2009 17:27:24 +0100 Message-ID: <3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com> From: "Paul B. Mahol" To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: qemu+aio vs C2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:27:26 -0000 On 2/26/09, Andriy Gapon wrote: > > I see something unusual and surprising for me: if I kldload aio for qemu's > sake > and then actually start qemu, I see that share of C2 in cx_usage is > constantly > dropping and then finally there is "too many short sleeps, backing off to > C1". > > This is on i386 with stable/7 as of r188116. > > I am out of ideas. And qemu guest is? Perhaps you should try changing guest kern.hz sysctl setting. I dont think related comitt got MFC-ed to STABLE. -- Paul From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 16:31:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FDA61065672 for ; Thu, 26 Feb 2009 16:31:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B070F8FC0C for ; Thu, 26 Feb 2009 16:31:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07408; Thu, 26 Feb 2009 18:31:38 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49A6C3EA.6060605@icyb.net.ua> Date: Thu, 26 Feb 2009 18:31:38 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49A6BFD1.6090601@icyb.net.ua> <3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com> In-Reply-To: <3a142e750902260827w722f110eve23a7bdb07cfbe42@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: qemu+aio vs C2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:31:43 -0000 on 26/02/2009 18:27 Paul B. Mahol said the following: > On 2/26/09, Andriy Gapon wrote: >> I see something unusual and surprising for me: if I kldload aio for qemu's >> sake >> and then actually start qemu, I see that share of C2 in cx_usage is >> constantly >> dropping and then finally there is "too many short sleeps, backing off to >> C1". >> >> This is on i386 with stable/7 as of r188116. >> >> I am out of ideas. > > And qemu guest is? > > Perhaps you should try changing guest kern.hz sysctl setting. > I dont think related comitt got MFC-ed to STABLE. > For what I've been doing the guest was our boot code and loader. Nothing beyond that. And, pardon me, how guest software could affect host's hardware in this way? As i understand only a hardware even of some sort could interrupt C2. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 17:44:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0E5106566C for ; Thu, 26 Feb 2009 17:44:23 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 26F8F8FC1B for ; Thu, 26 Feb 2009 17:44:22 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so445095ywt.13 for ; Thu, 26 Feb 2009 09:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=sDf75vpK60xNNxX31PoCWkZcu8+NPq/lO2/Hgm6Rvxc=; b=ADWTBdlqyxYBrWwstDaEHuHagB5ynW98FSMoVr2j21ZhOyXkP2fcWk3m7mXnHEDNa4 M//yRwRZIobE9xO1kUxYd76Che2XTXH9trHQKQW9aCDi55dURvS47ZKuGCansxYOrjOU Thqye5Nz940tDGtb9/NOkAkp5OSIC1dHd5vLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=laYiqhicT+UhaEi6Scm0r5REJvF8l9e5VoeCZeF5vBdAZ+7cZzrwfGWSnaGLy52C/K UOuHIkmLsXpCpMXjg6yg9JXlzjr7wA7akVRM9IEcRXqyp7ohqSQXQwBvIOiGvgdQ/c5t BfaiqOTiJJY2kNYJYegGHDAPgJ+ESTb1lss4U= MIME-Version: 1.0 Received: by 10.90.98.13 with SMTP id v13mr788664agb.102.1235670256486; Thu, 26 Feb 2009 09:44:16 -0800 (PST) Date: Thu, 26 Feb 2009 09:44:16 -0800 Message-ID: From: Ross Penner To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:44:23 -0000 Hi, When I enable powerd, it is only but a matter of time before my machine will lock up completely. I've had this problem since I've migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any problems. I doesn't seem to create a dump so I've had no luck on that end. I'm quite perplexed on how to proceed to help get this problem documented so it can be fixed. #uname -a FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 00:38:44 PST 2009 ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 Is there anything else I con provide that would be of assistance? Thank you, Ross Penner From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 17:55:07 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B11E1106566C; Thu, 26 Feb 2009 17:55:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 863FB8FC1E; Thu, 26 Feb 2009 17:55:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1QHt5Lr058952; Thu, 26 Feb 2009 12:55:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1QHt5wK034681; Thu, 26 Feb 2009 12:55:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id E7E431B5060; Thu, 26 Feb 2009 12:55:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090226175504.E7E431B5060@freebsd-stable.sentex.ca> Date: Thu, 26 Feb 2009 12:55:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:55:08 -0000 TB --- 2009-02-26 16:35:32 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-02-26 16:35:32 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-02-26 16:35:32 - cleaning the object tree TB --- 2009-02-26 16:35:56 - cvsupping the source tree TB --- 2009-02-26 16:35:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-02-26 16:36:05 - building world TB --- 2009-02-26 16:36:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 16:36:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 16:36:05 - TARGET=powerpc TB --- 2009-02-26 16:36:05 - TARGET_ARCH=powerpc TB --- 2009-02-26 16:36:05 - TZ=UTC TB --- 2009-02-26 16:36:05 - __MAKE_CONF=/dev/null TB --- 2009-02-26 16:36:05 - cd /src TB --- 2009-02-26 16:36:05 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 26 16:36:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 26 17:42:38 UTC 2009 TB --- 2009-02-26 17:42:38 - generating LINT kernel config TB --- 2009-02-26 17:42:38 - cd /src/sys/powerpc/conf TB --- 2009-02-26 17:42:38 - /usr/bin/make -B LINT TB --- 2009-02-26 17:42:38 - building LINT kernel TB --- 2009-02-26 17:42:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 17:42:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 17:42:38 - TARGET=powerpc TB --- 2009-02-26 17:42:38 - TARGET_ARCH=powerpc TB --- 2009-02-26 17:42:38 - TZ=UTC TB --- 2009-02-26 17:42:38 - __MAKE_CONF=/dev/null TB --- 2009-02-26 17:42:38 - cd /src TB --- 2009-02-26 17:42:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 17:42:38 UTC 2009 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror vers.c linking kernel vm_map.o(.text+0x3938): In function `vm_map_find': : undefined reference to `pmap_align_superpage' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-26 17:55:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-26 17:55:04 - ERROR: failed to build lint kernel TB --- 2009-02-26 17:55:04 - 3990.27 user 374.40 system 4771.90 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 18:43:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7889A106567A; Thu, 26 Feb 2009 18:43:48 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 094F18FC20; Thu, 26 Feb 2009 18:43:47 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1QI40RZ034232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Feb 2009 19:04:00 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1QI6QIQ003452; Thu, 26 Feb 2009 19:06:26 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1QI6PrV003451; Thu, 26 Feb 2009 19:06:25 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Weongyo Jeong From: Bengt Ahlgren In-Reply-To: <20090226045340.GC70144@weongyo.cdnetworks.kr> (Weongyo Jeong's message of "Thu\, 26 Feb 2009 13\:53\:40 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> Date: Thu, 26 Feb 2009 19:06:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nathan Butcher , freebsd-stable@freebsd.org Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:43:49 -0000 Weongyo Jeong writes: > On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >> >> Typically, It works for a while until eventually it stalls data >> transfers completely. It always seems to do this after an unspecified >> amount of time. >> >> I know the hardware isn't at fault because the device works fine under >> Linux. > > Could you please check that `ifconfig -bgscan' disabling the > background scan helps your symptom? The above sounds like the same problem as this: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html The problem is in the background scanning logic in sys/net80211. Bengt From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 18:54:51 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE5701065680; Thu, 26 Feb 2009 18:54:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 813A38FC0C; Thu, 26 Feb 2009 18:54:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1QIsnip067500; Thu, 26 Feb 2009 13:54:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1QIsnvZ076162; Thu, 26 Feb 2009 13:54:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 0370D1B5060; Thu, 26 Feb 2009 13:54:49 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090226185449.0370D1B5060@freebsd-stable.sentex.ca> Date: Thu, 26 Feb 2009 13:54:49 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:54:53 -0000 TB --- 2009-02-26 17:42:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-02-26 17:42:23 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-02-26 17:42:23 - cleaning the object tree TB --- 2009-02-26 17:42:41 - cvsupping the source tree TB --- 2009-02-26 17:42:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-02-26 17:42:51 - building world TB --- 2009-02-26 17:42:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 17:42:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 17:42:51 - TARGET=sparc64 TB --- 2009-02-26 17:42:51 - TARGET_ARCH=sparc64 TB --- 2009-02-26 17:42:51 - TZ=UTC TB --- 2009-02-26 17:42:51 - __MAKE_CONF=/dev/null TB --- 2009-02-26 17:42:51 - cd /src TB --- 2009-02-26 17:42:51 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 26 17:42:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 26 18:42:22 UTC 2009 TB --- 2009-02-26 18:42:22 - generating LINT kernel config TB --- 2009-02-26 18:42:22 - cd /src/sys/sparc64/conf TB --- 2009-02-26 18:42:22 - /usr/bin/make -B LINT TB --- 2009-02-26 18:42:23 - building LINT kernel TB --- 2009-02-26 18:42:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-26 18:42:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-26 18:42:23 - TARGET=sparc64 TB --- 2009-02-26 18:42:23 - TARGET_ARCH=sparc64 TB --- 2009-02-26 18:42:23 - TZ=UTC TB --- 2009-02-26 18:42:23 - __MAKE_CONF=/dev/null TB --- 2009-02-26 18:42:23 - cd /src TB --- 2009-02-26 18:42:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 26 18:42:23 UTC 2009 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c linking kernel vm_map.o(.text+0x3324): In function `vm_map_find': : undefined reference to `pmap_align_superpage' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-26 18:54:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-26 18:54:48 - ERROR: failed to build lint kernel TB --- 2009-02-26 18:54:48 - 3800.23 user 368.36 system 4345.76 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 20:07:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE4241065691 for ; Thu, 26 Feb 2009 20:07:56 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 74B2F8FC20 for ; Thu, 26 Feb 2009 20:07:56 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by bwz8 with SMTP id 8so682350bwz.43 for ; Thu, 26 Feb 2009 12:07:55 -0800 (PST) Received: by 10.223.111.19 with SMTP id q19mr2455215fap.58.1235678874109; Thu, 26 Feb 2009 12:07:54 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 13sm4674154fks.27.2009.02.26.12.07.50 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 12:07:53 -0800 (PST) From: "SDH Support" To: References: <49A6BFD1.6090601@icyb.net.ua> In-Reply-To: <49A6BFD1.6090601@icyb.net.ua> Date: Thu, 26 Feb 2009 15:07:36 -0500 Message-ID: <000601c9984d$e12b12d0$a3813870$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcmYLVX3zIBj3oVWRAilbzAWoD+/RgAIC3vw Content-Language: en-us Cc: Subject: RE: qemu+aio vs C2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@stardothosting.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:07:57 -0000 > I see something unusual and surprising for me: if I kldload aio for > qemu's sake > and then actually start qemu, I see that share of C2 in cx_usage is > constantly > dropping and then finally there is "too many short sleeps, backing off > to C1". >=20 > This is on i386 with stable/7 as of r188116. I've been running qemu w/ stable-7 with no problems. Could you paste the = actual error messages as well as a full DMESG? # uname -a FreeBSD kkutzko 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Oct 10 = 13:10:49 EDT 2008 server.local:/usr/obj/usr/src/sys/KK i386 # --- Kevin=20 Systems Administrator http://www.stardothosting.com/linux-vps-hosting http://wiki.stardothosting.com=20 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 20:36:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01499106564A; Thu, 26 Feb 2009 20:36:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C56ED8FC08; Thu, 26 Feb 2009 20:36:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 4ADA046B3B; Thu, 26 Feb 2009 15:36:29 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1QKaNfQ044842; Thu, 26 Feb 2009 15:36:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 26 Feb 2009 15:36:21 -0500 User-Agent: KMail/1.9.7 References: <20090226185449.0370D1B5060@freebsd-stable.sentex.ca> In-Reply-To: <20090226185449.0370D1B5060@freebsd-stable.sentex.ca> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200902261536.21497.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Feb 2009 15:36:23 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9051/Thu Feb 26 08:08:01 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: FreeBSD Tinderbox , sparc64@freebsd.org Subject: Re: [releng_7 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:36:30 -0000 On Thursday 26 February 2009 1:54:49 pm FreeBSD Tinderbox wrote: > [...] > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=15000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > -mcmodel=medany -msoft-float -ffreestanding -Werror vers.c > linking kernel > vm_map.o(.text+0x3324): In function `vm_map_find': > : undefined reference to `pmap_align_superpage' > *** Error code 1 Gah, sorry for the breakage. I have found the relevant change in HEAD to MFC and am trying to merge it, but am having some issues with NFS at the moment that are making it take a while. The two SVN changes I've found so far that are relevant are 175397 and 178893. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 21:22:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA14E106564A; Thu, 26 Feb 2009 21:22:18 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 79BE18FC21; Thu, 26 Feb 2009 21:22:18 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1QLMHgK092047; Thu, 26 Feb 2009 15:22:17 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1QLMIsU032346; Thu, 26 Feb 2009 15:22:18 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49A70807.9020600@palisadesys.com> Date: Thu, 26 Feb 2009 15:22:15 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Baldwin References: <49A46AB4.3080003@palisadesys.com> <200902250915.57562.jhb@freebsd.org> <49A55D78.1070604@palisadesys.com> <200902261012.24325.jhb@freebsd.org> In-Reply-To: <200902261012.24325.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Thu, 26 Feb 2009 15:22:18 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.799, required 6, ALL_TRUSTED -1.80, BAYES_00 -2.60, J_CHICKENPOX_48 0.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:22:19 -0000 John Baldwin wrote: > On Wednesday 25 February 2009 10:02:16 am Guy Helmer wrote: > >> John Baldwin wrote: >> >>> On Tuesday 24 February 2009 4:46:28 pm Guy Helmer wrote: >>> >>> >>>> I think I may have found a clue regarding some of the hangs I'm seeing >>>> on FreeBSD 7.1. >>>> I have a program (kvoop), compiled under FreeBSD 6 and using >>>> compatibility libraries under FreeBSD 7, that seems to be consistently >>>> involved during these hangs. This time, I noticed that many processes >>>> are stopped, waiting on the ufs lock. I can't tell for certain, but I >>>> assume this kvoop process 33203 is blocking the other processes. The >>>> kvoop process looks to me like it is waiting for a mutex, but nothing >>>> shows up being deadlocked. Am I on the right track? Is there something >>>> else I should be looking for? >>>> >>>> (kgdb) proc 33203 >>>> [Switching to thread 129 (Thread 100241)]#0 sched_switch ( >>>> td=0xffffff0019109a50, newtd=0x0, flags=1) >>>> at ../../../kern/sched_ule.c:1944 >>>> 1944 cpuid = PCPU_GET(cpuid); >>>> (kgdb) where >>>> #0 sched_switch (td=0xffffff0019109a50, newtd=0x0, flags=1) >>>> at ../../../kern/sched_ule.c:1944 >>>> #1 0xffffffff803a573b in mi_switch (flags=1, newtd=0x0) >>>> at ../../../kern/kern_synch.c:440 >>>> #2 0xffffffff803d1214 in turnstile_wait (ts=Variable "ts" is not available. >>>> ) >>>> at ../../../kern/subr_turnstile.c:748 >>>> #3 0xffffffff80392db0 in _mtx_lock_sleep (m=0xffffffff8083c220, >>>> tid=18446742974618442320, opts=Variable "opts" is not available. >>>> ) at ../../../kern/kern_mutex.c:420 >>>> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, >>>> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) >>>> at ../../../kern/kern_mutex.c:186 >>>> #5 0xffffffff80403bc6 in cache_lookup (dvp=0xffffff00013e0dc8, >>>> vpp=0xffffffffa2d93a18, cnp=0xffffffffa2d93a40) >>>> at ../../../kern/vfs_cache.c:327 >>>> #6 0xffffffff80404093 in vfs_cache_lookup (ap=Variable "ap" is not >>>> available. >>>> ) >>>> at ../../../kern/vfs_cache.c:674 >>>> #7 0xffffffff805628a0 in VOP_LOOKUP_APV (vop=0xffffffff8076e440, >>>> a=0xffffffffa2d936b0) at vnode_if.c:99 >>>> #8 0xffffffff80409afd in lookup (ndp=0xffffffffa2d939f0) at vnode_if.h:57 >>>> #9 0xffffffff8040a824 in namei (ndp=0xffffffffa2d939f0) >>>> at ../../../kern/vfs_lookup.c:219 >>>> #10 0xffffffff8041dc4f in vn_open_cred (ndp=0xffffffffa2d939f0, >>>> flagp=0xffffffffa2d9393c, cmode=0, cred=0xffffff0001588600, >>>> fp=0xffffff0001964200) at ../../../kern/vfs_vnops.c:188 >>>> #11 0xffffffff8041ccc7 in kern_open (td=0xffffff0019109a50, >>>> path=0xffffac30
, pathseg=Variable >>>> "pathseg" is not available. >>>> ) >>>> at ../../../kern/vfs_syscalls.c:1032 >>>> #12 0xffffffff80544660 in ia32_syscall (frame=0xffffffffa2d93c80) >>>> at ../../../amd64/ia32/ia32_syscall.c:182 >>>> #13 0xffffffff805014d0 in Xint0x80_syscall () at ia32_exception.S:65 >>>> #14 0x0000000028284037 in ?? () >>>> >>>> (kgdb) frame 4 >>>> #4 0xffffffff80392ea6 in _mtx_lock_flags (m=0xffffffff8083c220, opts=0, >>>> file=0xffffffff805bd438 "../../../kern/vfs_cache.c", line=327) >>>> at ../../../kern/kern_mutex.c:186 >>>> 186 _get_sleep_lock(m, curthread, opts, file, line); >>>> (kgdb) list >>>> 181 ("mtx_lock() of spin mutex %s @ %s:%d", >>>> m->lock_object.lo_name, >>>> 182 file, line)); >>>> 183 WITNESS_CHECKORDER(&m->lock_object, opts | LOP_NEWORDER >>>> | LOP_EXCLUSIVE, >>>> 184 file, line); >>>> 185 >>>> 186 _get_sleep_lock(m, curthread, opts, file, line); >>>> 187 LOCK_LOG_LOCK("LOCK", &m->lock_object, opts, >>>> m->mtx_recurse, file, >>>> 188 line); >>>> 189 WITNESS_LOCK(&m->lock_object, opts | LOP_EXCLUSIVE, >>>> file, line); >>>> 190 curthread->td_locks++; >>>> >>>> (kgdb) print *m >>>> $2 = {lock_object = {lo_name = 0xffffffff805bd5d2 "Name Cache", >>>> lo_type = 0xffffffff805bd5d2 "Name Cache", lo_flags = 16973824, >>>> lo_witness_data = {lod_list = {stqe_next = 0xffffffff807cd600}, >>>> lod_witness = 0xffffffff807cd600}}, mtx_lock = 4, mtx_recurse = 0} >>>> >>>> >>> Is this from a coredump or while the system is live? mtx_lock = 4 indicates >>> the mutex is unlocked, so there shouldn't be any threads waiting on it. >>> >>> >>> >> That was from running kgdb on a vmcore file. Would the state of the >> mutex be different than if I was running kgdb on a live kernel? >> > > Well, if it was live perhaps the thread wasn't hung but was changing states > while you were watching it. However, that is not true in a coredump. This is > a very disturbing bug as it means something is broken in the mutex implementation > itself. Have you reproduced this on multiple machines? > > The trace above is from a Supermicro X6DHR-8G motherboard with dual 3.6GHz Nocona Xeons running the amd64 architecture w/ SCHED_ULE. Here is a similar situation on a completely different machine running the same process load -- Supermicro P4DPR-8G2 with dual 2.4GHz Xeons -- running the i386 architecture w/ SCHED_ULE. Process 23092 has exclusive sx "user map" and is waiting on mutex "vm page queue mutex"; a bunch of other processes are stuck on allproc because a vmstat process has the allproc lock and is waiting on the "user map" exclusive lock held by proc 23092. First, from ddb: db> show alllocks Process 23110 (vmstat) thread 0xc5e3b230 (100181) shared sx allproc r = 0 (0xc0907edc) locked @ vm/vm_meter.c:130 exclusive sx sysctl lock r = 0 (0xc09083d4) locked @ kern/kern_sysctl.c:1397 Process 23092 (kvoop) thread 0xc60d2d20 (100208) exclusive sleep mutex vm object (standard object) r = 0 (0xc6043000) locked @ vm/vm_map.c:1476 exclusive sx user map r = 0 (0xc49eec0c) locked @ vm/vm_map.c:1211 Process 23090 (filter) thread 0xc5e2f000 (100199) shared sx filedesc structure r = 0 (0xc5e4cb2c) locked @ kern/kern_descrip.c:2062 Process 22521 (postgres) thread 0xc60d3000 (100207) exclusive sx so_rcv_sx r = 0 (0xc6174bec) locked @ kern/uipc_sockbuf.c:148 Process 7257 (tcsh) thread 0xc47db8c0 (100077) shared sx proctree r = 0 (0xc0907ef4) locked @ kern/kern_fork.c:300 Process 7253 (sshd) thread 0xc60d2690 (100211) exclusive sx so_rcv_sx r = 0 (0xc4c193cc) locked @ kern/uipc_sockbuf.c:148 Process 4570 (postgres) thread 0xc4ca68c0 (100139) exclusive sx so_rcv_sx r = 0 (0xc5f77d8c) locked @ kern/uipc_sockbuf.c:148 Process 2225 (postgres) thread 0xc47e1460 (100078) exclusive sx so_rcv_sx r = 0 (0xc4cca3cc) locked @ kern/uipc_sockbuf.c:148 Process 2128 (postgres) thread 0xc49e6000 (100128) exclusive sx so_rcv_sx r = 0 (0xc4cca3cc) locked @ kern/uipc_sockbuf.c:148 Process 2128 (postgres) thread 0xc49e6000 (100128) exclusive sx so_rcv_sx r = 0 (0xc491bd8c) locked @ kern/uipc_sockbuf.c:148 Process 2112 (perform_ca) thread 0xc47dcd20 (100051) shared sx proctree r = 0 (0xc0907ef4) locked @ kern/kern_fork.c:300 Process 1914 (postgres) thread 0xc49ead20 (100115) exclusive sx so_rcv_sx r = 0 (0xc491c70c) locked @ kern/uipc_sockbuf.c:148 Process 1499 (ph_alert_mgr) thread 0xc47db460 (100080) shared sx proctree r = 0 (0xc0907ef4) locked @ kern/kern_fork.c:300 Process 1482 (postgres) thread 0xc49c4d20 (100105) shared sx proctree r = 0 (0xc0907ef4) locked @ kern/kern_fork.c:300 db> show sleepchain 23110 thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK thread 100208 (pid 23092, kvoop) is on a run queue db> show sleepchain 23092 thread 100208 (pid 23092, kvoop) is on a run queue db> show sleepchain 23090 thread 100199 (pid 23090, filter) running on CPU 3 db> show sleepchain 22521 thread 100207 (pid 22521, postgres) sleeping on 0xc6174c1c "sbwait" db> show sleepchain 7257 thread 100077 (pid 7257, tcsh) blocked on sx "allproc" SLOCK (count 1) db> show sleepchain 2112 thread 100051 (pid 2112, perform_ca) blocked on sx "allproc" SLOCK (count 1) db> show sleepchain 1499 thread 100080 (pid 1499, initial thread) blocked on sx "allproc" SLOCK (count 1) db> show sleepchain 1482 thread 100105 (pid 1482, initial thread) blocked on sx "allproc" SLOCK (count 1) From kgdb on the vmcore file: (kgdb) proc 23092 [Switching to thread 132 (Thread 100208)]#0 sched_switch (td=0xc60d2d20, newtd=Variable "newtd" is not available. ) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) where #0 sched_switch (td=0xc60d2d20, newtd=Variable "newtd" is not available. ) at ../../../kern/sched_ule.c:1944 #1 0xc065d073 in mi_switch (flags=Variable "flags" is not available. ) at ../../../kern/kern_synch.c:440 #2 0xc06872a4 in turnstile_wait (ts=0xc60d46e0, owner=0xc49c4460, queue=0) at ../../../kern/subr_turnstile.c:748 #3 0xc064931e in _mtx_lock_sleep (m=0xc09635dc, tid=3322752288, opts=0, file=0xc086a6ef "../../../vm/vm_map.c", line=1543) at ../../../kern/kern_mutex.c:420 #4 0xc06493a7 in _mtx_lock_flags (m=0xc09635dc, opts=0, file=0xc086a6ef "../../../vm/vm_map.c", line=1543) at ../../../kern/kern_mutex.c:186 #5 0xc07a7010 in vm_map_pmap_enter (map=0xc49eebc8, addr=1210679296, prot=5 '\005', object=0xc6043000, pindex=0, size=204800, flags=16) at ../../../vm/vm_map.c:1543 #6 0xc07a7366 in vm_map_insert (map=0xc49eebc8, object=0xc6043000, offset=0, start=1210679296, end=1210884096, prot=Variable "prot" is not available. ) at ../../../vm/vm_map.c:1072 #7 0xc07a8a22 in vm_map_find (map=0xc49eebc8, object=0xc6043000, offset=0, addr=0xe6fccc6c, length=204800, find_space=1, prot=Variable "prot" is not available. ) at ../../../vm/vm_map.c:1219 #8 0xc07ab2d3 in vm_mmap (map=0xc49eebc8, addr=0xe6fccc6c, size=204800, prot=Variable "prot" is not available. ) at ../../../vm/vm_mmap.c:1411 #9 0xc07abae8 in mmap (td=0xc60d2d20, uap=0xe6fcccfc) at ../../../vm/vm_mmap.c:377 #10 0xc07f8343 in syscall (frame=0xe6fccd38) at ../../../i386/i386/trap.c:1090 ---Type to continue, or q to quit--- #11 0xc07e0340 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 4 #4 0xc06493a7 in _mtx_lock_flags (m=0xc09635dc, opts=0, file=0xc086a6ef "../../../vm/vm_map.c", line=1543) at ../../../kern/kern_mutex.c:186 186 _get_sleep_lock(m, curthread, opts, file, line); (kgdb) print *m $3 = {lock_object = {lo_name = 0xc085951a "vm page queue mutex", lo_type = 0xc085951a "vm page queue mutex", lo_flags = 25886720, lo_witness_data = {lod_list = {stqe_next = 0xc091d1a0}, lod_witness = 0xc091d1a0}}, mtx_lock = 4, mtx_recurse = 0} From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 21:48:47 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B755106564A for ; Thu, 26 Feb 2009 21:48:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F02478FC15 for ; Thu, 26 Feb 2009 21:48:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8822A46BA5; Thu, 26 Feb 2009 16:48:46 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1QLme6N045657; Thu, 26 Feb 2009 16:48:40 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Guy Helmer Date: Thu, 26 Feb 2009 16:48:32 -0500 User-Agent: KMail/1.9.7 References: <49A46AB4.3080003@palisadesys.com> <200902261012.24325.jhb@freebsd.org> <49A70807.9020600@palisadesys.com> In-Reply-To: <49A70807.9020600@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902261648.32845.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Feb 2009 16:48:40 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9051/Thu Feb 26 08:08:01 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:48:47 -0000 On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: > db> show sleepchain 23110 > thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK > thread 100208 (pid 23092, kvoop) is on a run queue > db> show sleepchain 23092 > thread 100208 (pid 23092, kvoop) is on a run queue Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue waiting for a CPU. Can you find the thread pointer for kvoop and check on things such as if it is pinned and if so to which CPU (td_pinned will tell you the first, and td_sched->ts_cpu will tell you the second with ULE). Then you will want to see what is running on that CPU. You might want to check your other coredump and find the td_state member of the thread for kvoop there as well. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 22:27:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB2E106564A; Thu, 26 Feb 2009 22:27:11 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF2F8FC0A; Thu, 26 Feb 2009 22:27:10 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1QMRAYb092403; Thu, 26 Feb 2009 16:27:10 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1QMRAtL034829; Thu, 26 Feb 2009 16:27:11 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49A7173B.4030608@palisadesys.com> Date: Thu, 26 Feb 2009 16:27:07 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Baldwin References: <49A46AB4.3080003@palisadesys.com> <200902261012.24325.jhb@freebsd.org> <49A70807.9020600@palisadesys.com> <200902261648.32845.jhb@freebsd.org> In-Reply-To: <200902261648.32845.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Thu, 26 Feb 2009 16:27:11 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:27:11 -0000 John Baldwin wrote: > On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: > >> db> show sleepchain 23110 >> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK >> thread 100208 (pid 23092, kvoop) is on a run queue >> db> show sleepchain 23092 >> thread 100208 (pid 23092, kvoop) is on a run queue >> > > Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue > waiting for a CPU. Can you find the thread pointer for kvoop and check on > things such as if it is pinned and if so to which CPU (td_pinned will tell > you the first, and td_sched->ts_cpu will tell you the second with ULE). > (kgdb) print td->td_pinned $2 = 0 (kgdb) print td->td_sched->ts_cpu $3 = 3 '\003' (kgdb) print td->td_state $4 = TDS_RUNQ From my captured ddb run: cpuid = 3 curthread = 0xc5e2f000: pid 23090 "filter" curpcb = 0xe6f90d90 fpcurthread = none idlethread = 0xc442daf0: pid 11 "idle: cpu3" APIC ID = 7 currentldt = 0x50 spin locks held: Back to kgdb: (kgdb) proc 23090 [Switching to thread 131 (Thread 100199)]#0 cpustop_handler () at atomic.h:253 253 ATOMIC_ASM(set, int, "orl %1,%0", "ir", v); (kgdb) where #0 cpustop_handler () at atomic.h:253 #1 0xc07eedef in ipi_nmi_handler () at ../../../i386/i386/mp_machdep.c:1300 #2 0xc07f85e0 in trap (frame=0xe6f90b64) at ../../../i386/i386/trap.c:216 #3 0xc07e02db in calltrap () at ../../../i386/i386/exception.s:159 #4 0xc068a066 in witness_unlock (lock=0xc5e4cb2c, flags=0, file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083) at ../../../kern/subr_witness.c:1266 #5 0xc065c95e in _sx_sunlock (sx=0xc5e4cb2c, file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083) at ../../../kern/kern_sx.c:294 #6 0xc062e1ab in fget_read (td=0xc5e2f000, fd=15, fpp=0xe6f90c34) at ../../../kern/kern_descrip.c:2083 #7 0xc068c2e8 in kern_readv (td=0xc5e2f000, fd=15, auio=0xe6f90c60) at ../../../kern/sys_generic.c:189 #8 0xc068c3ff in read (td=0xc5e2f000, uap=0xe6f90cfc) at ../../../kern/sys_generic.c:108 #9 0xc07f8343 in syscall (frame=0xe6f90d38) at ../../../i386/i386/trap.c:1090 #10 0xc07e0340 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 4 #4 0xc068a066 in witness_unlock (lock=0xc5e4cb2c, flags=0, file=0xc08529f0 "../../../kern/kern_descrip.c", line=2083) at ../../../kern/subr_witness.c:1266 1266 if (witness_cold || witness_watch == 0 || lock->lo_witness == NULL || (kgdb) print *lock $5 = {lo_name = 0xc0852b03 "filedesc structure", lo_type = 0xc0852b03 "filedesc structure", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0xc091c228}, lod_witness = 0xc091c228}} > Then you will want to see what is running on that CPU. You might want to > check your other coredump and find the td_state member of the thread for > kvoop there as well. > On the amd64, kvoop was on the run queue for cpu 1 and another process, filter, looks like it must have been running in user mode when I broke into ddb: (kgdb) proc 33201 [Switching to thread 127 (Thread 100113)]#0 cpustop_handler () at atomic.h:264 264 ATOMIC_ASM(set, int, "orl %1,%0", "ir", v); (kgdb) where #0 cpustop_handler () at atomic.h:264 #1 0xffffffff8050c560 in ipi_nmi_handler () at ../../../amd64/amd64/mp_machdep.c:1119 #2 0xffffffff8051aba7 in trap (frame=0xffffffff9fe18f40) at ../../../amd64/amd64/trap.c:198 #3 0xffffffff805013eb in nmi_calltrap () at ../../../amd64/amd64/exception.S:427 #4 0x00000000280af9d4 in ?? () Previous frame inner to this frame (corrupt stack?) I sure wish I could find the root cause of the hangs. On a hunch, I tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it has run 32 hours without a hang. It could just be coincidence, though... Thanks for your help, Guy From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 22:47:25 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24EF01065689 for ; Thu, 26 Feb 2009 22:47:25 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f166.google.com (mail-ew0-f166.google.com [209.85.219.166]) by mx1.freebsd.org (Postfix) with ESMTP id AAF068FC1E for ; Thu, 26 Feb 2009 22:47:24 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy10 with SMTP id 10so951325ewy.43 for ; Thu, 26 Feb 2009 14:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y3OHNLtXlTKwuE5G7f/iIILdTxgUOD+gamuO7A8xkUo=; b=ob6sYxP31ESx7oeS1tmBx2RfrwOz53aUCCU+gG1hj/6eo/wsap5kPauy2gRL9K9Hag Xq5oGOnCheqv3dZbTASKKQZX1pDrt74JG2Cyi1pzsbnInyC2LGAlyV/M8uSikJGrFhnH 7zB7/guLGf/I6/wPFuY2AxOTysGyAwqWAJfWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GBhDKnZEbmp1QBozAiUoihmgJ2TJiHKT9f8wkpl2Xo/Ln2jQL/JaUavIabcfMqbkDc gUYKfK2JYOw0w0bCGMAMWVpV6Ii89vdaGonO1nudv6A9ACAEyGhoT4d9cTwDewN25eC8 iLps6kxm6dEKdAVqnvzVK26+SeZbR8G1qOcxU= MIME-Version: 1.0 Received: by 10.210.91.7 with SMTP id o7mr1271884ebb.39.1235688443739; Thu, 26 Feb 2009 14:47:23 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2009 23:47:23 +0100 Message-ID: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> From: "Paul B. Mahol" To: Ross Penner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:47:25 -0000 On 2/26/09, Ross Penner wrote: > Hi, > > When I enable powerd, it is only but a matter of time before my > machine will lock up completely. I've had this problem since I've > migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any > problems. I doesn't seem to create a dump so I've had no luck on that > end. I'm quite perplexed on how to proceed to help get this problem > documented so it can be fixed. > > #uname -a > FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 > 00:38:44 PST 2009 > ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 > > Is there anything else I con provide that would be of assistance? I'm aware of livelock between syscons and powerd which is not trivial to reproduce (at least for me). Does it locks in Xorg too? -- Paul From owner-freebsd-stable@FreeBSD.ORG Thu Feb 26 22:53:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA29106566C for ; Thu, 26 Feb 2009 22:53:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF6288FC1D for ; Thu, 26 Feb 2009 22:53:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 0B20B46B23; Thu, 26 Feb 2009 17:53:45 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1QMrdmV046022; Thu, 26 Feb 2009 17:53:39 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Guy Helmer Date: Thu, 26 Feb 2009 17:53:29 -0500 User-Agent: KMail/1.9.7 References: <49A46AB4.3080003@palisadesys.com> <200902261648.32845.jhb@freebsd.org> <49A7173B.4030608@palisadesys.com> In-Reply-To: <49A7173B.4030608@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902261753.29607.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Feb 2009 17:53:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9051/Thu Feb 26 08:08:01 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:53:46 -0000 On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote: > John Baldwin wrote: > > On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: > > > >> db> show sleepchain 23110 > >> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK > >> thread 100208 (pid 23092, kvoop) is on a run queue > >> db> show sleepchain 23092 > >> thread 100208 (pid 23092, kvoop) is on a run queue > >> > > > > Ah, so this is normal (well, mostly) in that kvoop is simply on the run queue > > waiting for a CPU. Can you find the thread pointer for kvoop and check on > > things such as if it is pinned and if so to which CPU (td_pinned will tell > > you the first, and td_sched->ts_cpu will tell you the second with ULE). > > > (kgdb) print td->td_pinned > $2 = 0 Ok, not pinned. > From my captured ddb run: > cpuid = 3 > curthread = 0xc5e2f000: pid 23090 "filter" > curpcb = 0xe6f90d90 > fpcurthread = none > idlethread = 0xc442daf0: pid 11 "idle: cpu3" > APIC ID = 7 > currentldt = 0x50 > spin locks held: At http://www.freebsd.org/~jhb/gdb/ you can find my kgdb scripts. If you source gdb6 you can run 'runtds' which will show you what each CPU is doing (more or less) in ps-style output. > I sure wish I could find the root cause of the hangs. On a hunch, I > tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it has > run 32 hours without a hang. It could just be coincidence, though... Ahhh, that actually could explain it perhaps. Do your CPUs support C2 or higher sleep states for idle? You can try limiting it to only C1 (or disable C1E in your BIOS if it has an option for that) to see if that fixes it. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 02:04:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38FF0106564A; Fri, 27 Feb 2009 02:04:18 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABE98FC18; Fri, 27 Feb 2009 02:04:17 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1R24HJX044340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 18:04:17 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49A74A21.1050109@freebsd.org> Date: Thu, 26 Feb 2009 18:04:17 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: Nathan Butcher , freebsd-stable@freebsd.org, Weongyo Jeong Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 02:04:18 -0000 Bengt Ahlgren wrote: > Weongyo Jeong writes: > > >> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >> >>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >>> >>> Typically, It works for a while until eventually it stalls data >>> transfers completely. It always seems to do this after an unspecified >>> amount of time. >>> >>> I know the hardware isn't at fault because the device works fine under >>> Linux. >>> >> Could you please check that `ifconfig -bgscan' disabling the >> background scan helps your symptom? >> > > The above sounds like the same problem as this: > > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > The problem is in the background scanning logic in sys/net80211. > > I don't see how you come to this conclusion. ural is a totally different driver than ath and so far as I can recall you never found the cause for your problem w/ ath. Most of the usb wireless drivers do a haphazard job of synchronizing async tasks like bg scan with the foreground tx/rx processing. This can lead to firmware and/or usb issues. ath does not have these issues but I am aware of at least one problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). Sam From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 03:56:00 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2221065670; Fri, 27 Feb 2009 03:56:00 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id F1E898FC0A; Fri, 27 Feb 2009 03:55:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so869757rvb.43 for ; Thu, 26 Feb 2009 19:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem; bh=nLfCEgXpH65KTILS67Dx1sKhLWebB+oCwm7zGZpMges=; b=lADQBV2tao+T4pA0pJLaASafji/tsXe/iK4jQyL4XrwwQDCiowWNlC7SaPpiwh3rTd jLxG9DanfBkQb5bXAeKxicPUMDTaorJQhy9mV6Y0ZiogBFDo4zefIuRy+GrMPdXq3/kj skCCvBOIcceU8rT2FDS2FY/1sVpROps0xqpKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :organization:x-operation-sytem; b=o/8guoxP756Xzz5QzENaLZ3keCon7A+nZtszpHZE6Mw9/m+6sYtHXaaiPK0OXGiGvA OVpHiSiqb2fPNaEcKO7zmehUAd4HgT7UgrLFRaXLCQP+WfZX1I7vPNLbSuOVDuGIO3+3 aALB/ZQW/2k+ZBzYN23IrgUW7j8x3Krn8Bn28= Received: by 10.140.132.4 with SMTP id f4mr969179rvd.211.1235706959706; Thu, 26 Feb 2009 19:55:59 -0800 (PST) Received: from weongyo ([114.111.62.249]) by mx.google.com with ESMTPS id c20sm1689141rvf.1.2009.02.26.19.55.57 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 19:55:59 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Fri, 27 Feb 2009 12:55:32 +0900 From: Weongyo Jeong Date: Fri, 27 Feb 2009 12:55:32 +0900 To: Bengt Ahlgren Message-ID: <20090227035532.GC72273@weongyo.cdnetworks.kr> References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A74A21.1050109@freebsd.org> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Nathan Butcher , Sam Leffler , freebsd-stable@freebsd.org Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 03:56:00 -0000 On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: > Bengt Ahlgren wrote: > >Weongyo Jeong writes: > > > >>On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: > >> > >>>I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. > >>>It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 > >>> > >>>Typically, It works for a while until eventually it stalls data > >>>transfers completely. It always seems to do this after an unspecified > >>>amount of time. > >>> > >>>I know the hardware isn't at fault because the device works fine under > >>>Linux. > >>> > >>Could you please check that `ifconfig -bgscan' disabling the > >>background scan helps your symptom? > > > >The above sounds like the same problem as this: > > > >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html > >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > > >The problem is in the background scanning logic in sys/net80211. > > I don't see how you come to this conclusion. ural is a totally > different driver than ath and so far as I can recall you never found the > cause for your problem w/ ath. Most of the usb wireless drivers do a > haphazard job of synchronizing async tasks like bg scan with the > foreground tx/rx processing. This can lead to firmware and/or usb > issues. ath does not have these issues but I am aware of at least one > problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). I agree with sam because I saw some cases like stalls during background scanning that most of them I think it's caused by H/W miss-operation or miss-configuration by mistakes of driver. regards, Weongyo Jeong From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 05:33:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4589106564A for ; Fri, 27 Feb 2009 05:33:20 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from smtp12.dentaku.gol.com (smtp12.dentaku.gol.com [203.216.5.74]) by mx1.freebsd.org (Postfix) with ESMTP id B26188FC14 for ; Fri, 27 Feb 2009 05:33:20 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[172.16.1.151]) by smtp12.dentaku.gol.com with esmtpsa (Dentaku) id 1LcvLZ-0007Vx-Nl; Fri, 27 Feb 2009 14:33:17 +0900 Message-ID: <49A77B1D.70801@fusiongol.com> Date: Fri, 27 Feb 2009 14:33:17 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Weongyo Jeong References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> In-Reply-To: <20090227035532.GC72273@weongyo.cdnetworks.kr> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com Cc: Sam Leffler , freebsd-stable@freebsd.org Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:33:21 -0000 Weongyo Jeong wrote: > On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >> Bengt Ahlgren wrote: >>> Weongyo Jeong writes: >>> >>>> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >>>> >>>>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >>>>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >>>>> >>>>> Typically, It works for a while until eventually it stalls data >>>>> transfers completely. It always seems to do this after an unspecified >>>>> amount of time. >>>>> >>>>> I know the hardware isn't at fault because the device works fine under >>>>> Linux. >>>>> >>>> Could you please check that `ifconfig -bgscan' disabling the >>>> background scan helps your symptom? >>> The above sounds like the same problem as this: >>> >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>> >>> The problem is in the background scanning logic in sys/net80211. >> I don't see how you come to this conclusion. ural is a totally >> different driver than ath and so far as I can recall you never found the >> cause for your problem w/ ath. Most of the usb wireless drivers do a >> haphazard job of synchronizing async tasks like bg scan with the >> foreground tx/rx processing. This can lead to firmware and/or usb >> issues. ath does not have these issues but I am aware of at least one >> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). > > I agree with sam because I saw some cases like stalls during background > scanning that most of them I think it's caused by H/W miss-operation or > miss-configuration by mistakes of driver. I'll do some testing without the bgscan and report back. (haven't had time recently) From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 05:50:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC580106564A for ; Fri, 27 Feb 2009 05:50:18 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3B78FC13 for ; Fri, 27 Feb 2009 05:50:17 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so635686yxl.13 for ; Thu, 26 Feb 2009 21:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VORReMI51QUAxpdlFdJacmIePrfg2aBD0XCEIDTBOY8=; b=IX6JA1mckz3BWEbuPmIDAa9cHUZRZtTHqZbQ4zj8Fc3v92JsrcMsKYgp3ictqb/UEQ qAlknyfUgSIBDm0lI+6CztD5qRoKqRd8pku0siw8WrbhbIaEuno8Dakz2YJSQvcNOPhg UxJwS0nSDszeof5H9ccZd7GyOjjqro0F5NY8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WikBpQPE2k1P2KXVzkGr1NaYRTE/1E7by6jf6lF+XQoBVde4m3O2lQYi76anqTq4+F i7fKyDDeMGTiT3DZYDZ94TjiYpTH5IyGdJ7r5BdiVStl6H3/Pepx8dxauPR+Rt9VjBm0 YByuOmi0/o6SCDD4SvaI9TbmNyEvhSbP9AKxw= MIME-Version: 1.0 Received: by 10.90.67.20 with SMTP id p20mr270090aga.10.1235713817291; Thu, 26 Feb 2009 21:50:17 -0800 (PST) In-Reply-To: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> References: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> Date: Thu, 26 Feb 2009 21:50:17 -0800 Message-ID: From: Ross Penner To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:50:19 -0000 Perhaps, but I rarely run Xorg. I use the machine as a gateway for our network in the house. I've noticed it most often when under a network load but that might not be a real correlation. On Thu, Feb 26, 2009 at 2:47 PM, Paul B. Mahol wrote: > On 2/26/09, Ross Penner wrote: >> Hi, >> >> When I enable powerd, it is only but a matter of time before my >> machine will lock up completely. I've had this problem since I've >> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any >> problems. I doesn't seem to create a dump so I've had no luck on that >> end. I'm quite perplexed on how to proceed to help get this problem >> documented so it can be fixed. >> >> #uname -a >> FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 >> 00:38:44 PST 2009 >> ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 =A0i386 >> >> Is there anything else I con provide that would be of assistance? > > I'm aware of livelock between syscons and powerd which is not trivial to > reproduce (at least for me). > Does it locks in Xorg too? > > -- > Paul > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 10:47:35 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C81106564A for ; Fri, 27 Feb 2009 10:47:35 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0333C8FC0C for ; Fri, 27 Feb 2009 10:47:34 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id DE5FF125422; Fri, 27 Feb 2009 19:30:20 +0900 (JST) Message-ID: <49A7C0BC.3070404@ongs.co.jp> Date: Fri, 27 Feb 2009 19:30:20 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: FreeBSD Current , stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: AsiaBSDCon 2009, early regist until 03/01/2009, dont miss it! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:47:35 -0000 Hi FreeBSD folks! AsiaBSDCon 2009 http://2009.asiabsdcon.org/ http://2009.asiabsdcon.org/registration.html AsiaBSDCon 2009 online registration is already begun and early registration is until 3/1 2009, you can save 3,000 YEN by early regist. Don't miss it :) I'm very glad to see you on AsiaBSDCon 2009! -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 11:46:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 995E4106566C for ; Fri, 27 Feb 2009 11:46:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f166.google.com (mail-ew0-f166.google.com [209.85.219.166]) by mx1.freebsd.org (Postfix) with ESMTP id 014D48FC19 for ; Fri, 27 Feb 2009 11:46:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy10 with SMTP id 10so1066828ewy.43 for ; Fri, 27 Feb 2009 03:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f87re7ZaHwoKzXlOi/6YG3XyAdH8f35YDaJ31std9ig=; b=jNPVEM6Qg8xil/Kjvwr2S+rZ+Ijv7OOS1IfXDMJPFQAPU/l7yvC4YbxaqYBv9c/gQ0 h3XYgeY9euCSPbrYGuEMbjFeQMp1+Mz8T0p1Op4n27rpOU7DBznbgiwJiQs1w7VI33cF mn42yTcbe+0FcHwvVr+0PGyx6fCZHpQLTh1KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eimKKinBSH9KZFcXMimB8H+Kn4oy4HwTW0gJjbT2D1hW/BL1PN5YnNWmaqtMeSr1DM Ck50cNhgFOuMGy5nFzXVGTss32Ss0JTrx/pyRTlzuFB9mMKU38MF/4iUgW5tBVtpOBcc Hc/IlKYHesxrmNweHS4uMozIp/XJhLsSarD18= MIME-Version: 1.0 Received: by 10.210.10.8 with SMTP id 8mr371294ebj.80.1235735202143; Fri, 27 Feb 2009 03:46:42 -0800 (PST) In-Reply-To: References: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> Date: Fri, 27 Feb 2009 12:46:42 +0100 Message-ID: <3a142e750902270346m4358ad19p9883e6a69bda9b01@mail.gmail.com> From: "Paul B. Mahol" To: Ross Penner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:46:44 -0000 On 2/27/09, Ross Penner wrote: > Perhaps, but I rarely run Xorg. I use the machine as a gateway for our > network in the house. I've noticed it most often when under a network > load but that might not be a real correlation. > > On Thu, Feb 26, 2009 at 2:47 PM, Paul B. Mahol wrote: >> On 2/26/09, Ross Penner wrote: >>> Hi, >>> >>> When I enable powerd, it is only but a matter of time before my >>> machine will lock up completely. I've had this problem since I've >>> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any >>> problems. I doesn't seem to create a dump so I've had no luck on that >>> end. I'm quite perplexed on how to proceed to help get this problem >>> documented so it can be fixed. >>> >>> #uname -a >>> FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 >>> 00:38:44 PST 2009 >>> ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 >>> >>> Is there anything else I con provide that would be of assistance? >> >> I'm aware of livelock between syscons and powerd which is not trivial to >> reproduce (at least for me). The locks happens for me only if kernel prints something on console while something other is being printed on vtys. So it looks like your problem is not related to syscons bugs. -- Paul From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 13:30:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6531F106564A for ; Fri, 27 Feb 2009 13:30:48 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 179CB8FC1B for ; Fri, 27 Feb 2009 13:30:48 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id A6E34130D13 for ; Fri, 27 Feb 2009 16:12:13 +0300 (MSK) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 560AB130CD7 for ; Fri, 27 Feb 2009 16:12:13 +0300 (MSK) Date: Fri, 27 Feb 2009 16:08:30 +0300 From: Igor Sysoev To: freebsd-stable@freebsd.org Message-ID: <20090227130830.GI51952@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 27022009 #1852067, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 7503 [Feb 27 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:30:48 -0000 Is anyone able to boot kernel with recently merged superpage support ? I have csup'd world to *default date=2009.02.26.23.59.59 then rebuild world and kernel does not boot: FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 XXXXXXXXXXXXXXXXXXXXX kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803b1d80 stack pointer = 0x10:0xffffffff80686ce0 frame pointer = 0x10:0xffffffff80686d00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () trap number = 12 panic: page fault cpuid = 0 And the message is cycled. The kernel does not boot despite vm.pmap.pg_ps_enabled value. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 14:19:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C40106566B; Fri, 27 Feb 2009 14:19:04 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8478FC17; Fri, 27 Feb 2009 14:19:04 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1REIdFe045569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Feb 2009 15:18:40 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1REL83s002558; Fri, 27 Feb 2009 15:21:08 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1REL6ZS002557; Fri, 27 Feb 2009 15:21:07 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Weongyo Jeong From: Bengt Ahlgren In-Reply-To: <20090227035532.GC72273@weongyo.cdnetworks.kr> (Weongyo Jeong's message of "Fri\, 27 Feb 2009 12\:55\:32 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> Date: Fri, 27 Feb 2009 15:21:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nathan Butcher , Sam Leffler , freebsd-stable@freebsd.org Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:19:05 -0000 Weongyo Jeong writes: > On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >> Bengt Ahlgren wrote: >> >Weongyo Jeong writes: >> > >> >>On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >> >> >> >>>I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >> >>>It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >> >>> >> >>>Typically, It works for a while until eventually it stalls data >> >>>transfers completely. It always seems to do this after an unspecified >> >>>amount of time. >> >>> >> >>>I know the hardware isn't at fault because the device works fine under >> >>>Linux. >> >>> >> >>Could you please check that `ifconfig -bgscan' disabling the >> >>background scan helps your symptom? >> > >> >The above sounds like the same problem as this: >> > >> >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html >> >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >> > >> >The problem is in the background scanning logic in sys/net80211. >> >> I don't see how you come to this conclusion. ural is a totally >> different driver than ath and so far as I can recall you never found the >> cause for your problem w/ ath. Most of the usb wireless drivers do a >> haphazard job of synchronizing async tasks like bg scan with the >> foreground tx/rx processing. This can lead to firmware and/or usb >> issues. ath does not have these issues but I am aware of at least one >> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). > > I agree with sam because I saw some cases like stalls during background > scanning that most of them I think it's caused by H/W miss-operation or > miss-configuration by mistakes of driver. Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same calls to net80211 which causes problems for ath. At line 1477, it has the same test as ath has to check for bg scanning: if (ic->ic_flags & IEEE80211_F_SCAN) ieee80211_cancel_scan(ic); That means that ieee80211_cancel_scan won't be called in the window between when scan_next is run (which resets IEEE80211_F_SCAN), and ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN again). This is the same problem as ath has. But I can't find that ural calls ieee80211_pwrsave to queue packets if a bgscan was running. It seems that it just merrily tries to send packets despite scanning is going on. Please note that even though ieee80211_cancel_scan IS called, that won't take effect until the next clock tick. So if the output routine just carries on with sending a packet, it will do so in the middle of the scan. This is something that should be fixed in net80211. So, I find that ural also suffers from the problem with the scanning logic in net80211. Bengt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 14:32:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D78E8106564A for ; Fri, 27 Feb 2009 14:32:09 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id AEB478FC08 for ; Fri, 27 Feb 2009 14:32:09 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0D98B2A3FF4; Fri, 27 Feb 2009 09:32:09 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 27 Feb 2009 09:32:09 -0500 X-Sasl-enc: z9h6CO4zQ1L9vH3RqPuKaZZIImyGr82g8TcV1fLLxVts 1235745128 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7F9F62C5FC; Fri, 27 Feb 2009 09:32:08 -0500 (EST) Message-ID: <49A7F973.9000500@incunabulum.net> Date: Fri, 27 Feb 2009 14:32:19 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Igor Sysoev References: <20090227130830.GI51952@rambler-co.ru> In-Reply-To: <20090227130830.GI51952@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:32:10 -0000 Igor Sysoev wrote: > Is anyone able to boot kernel with recently merged superpage support ? > I have csup'd world to > *default date=2009.02.26.23.59.59 > then rebuild world and kernel does not boot: > > FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 > XXXXXXXXXXXXXXXXXXXXX > kernel trap 12 with interrupts disabled > +1. Attempting to set the tunable at boot time doesn't work for me either. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 15:26:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32B41065673 for ; Fri, 27 Feb 2009 15:26:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B31EF8FC27 for ; Fri, 27 Feb 2009 15:26:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 4B21446B2E; Fri, 27 Feb 2009 10:26:27 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1RFQLtC052243; Fri, 27 Feb 2009 10:26:21 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 27 Feb 2009 10:26:15 -0500 User-Agent: KMail/1.9.7 References: <20090227130830.GI51952@rambler-co.ru> In-Reply-To: <20090227130830.GI51952@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902271026.15796.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 27 Feb 2009 10:26:21 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9054/Fri Feb 27 04:02:52 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:26:28 -0000 On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > Is anyone able to boot kernel with recently merged superpage support ? > I have csup'd world to > *default date=2009.02.26.23.59.59 > then rebuild world and kernel does not boot: > > FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 > XXXXXXXXXXXXXXXXXXXXX > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff803b1d80 > stack pointer = 0x10:0xffffffff80686ce0 > frame pointer = 0x10:0xffffffff80686d00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > trap number = 12 > panic: page fault > cpuid = 0 > > And the message is cycled. The kernel does not boot despite > vm.pmap.pg_ps_enabled value. This should now be fixed, apologies for the breakage. :( -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 15:44:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21FA1106566B; Fri, 27 Feb 2009 15:44:22 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cetus.palisadesys.com (cetus.palisadesys.com [205.237.115.21]) by mx1.freebsd.org (Postfix) with ESMTP id D8A518FC19; Fri, 27 Feb 2009 15:44:21 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from cancer.palisadesys.com (serverwatch [172.16.1.98]) by cetus.palisadesys.com (8.14.3/8.14.3) with ESMTP id n1RFiK8v097931; Fri, 27 Feb 2009 09:44:20 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [205.237.115.21]) (authenticated bits=0) by cancer.palisadesys.com (8.14.2/8.14.2) with ESMTP id n1RFiMYI059474; Fri, 27 Feb 2009 09:44:22 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <49A80A55.5070004@palisadesys.com> Date: Fri, 27 Feb 2009 09:44:21 -0600 From: Guy Helmer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Baldwin References: <49A46AB4.3080003@palisadesys.com> <200902261648.32845.jhb@freebsd.org> <49A7173B.4030608@palisadesys.com> <200902261753.29607.jhb@freebsd.org> In-Reply-To: <200902261753.29607.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (cancer.palisadesys.com [205.237.115.20]); Fri, 27 Feb 2009 09:44:22 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Cc: freebsd-stable@freebsd.org Subject: Re: 7.1 hangs in cache_lookup mutex? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:44:23 -0000 John Baldwin wrote: > On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote: > >> John Baldwin wrote: >> >>> On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote: >>> >>> >>>> db> show sleepchain 23110 >>>> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK >>>> thread 100208 (pid 23092, kvoop) is on a run queue >>>> db> show sleepchain 23092 >>>> thread 100208 (pid 23092, kvoop) is on a run queue >>>> >>>> >>> Ah, so this is normal (well, mostly) in that kvoop is simply on the run >>> > queue > >>> waiting for a CPU. Can you find the thread pointer for kvoop and check on >>> things such as if it is pinned and if so to which CPU (td_pinned will tell >>> you the first, and td_sched->ts_cpu will tell you the second with ULE). >>> >>> >> (kgdb) print td->td_pinned >> $2 = 0 >> > > Ok, not pinned. > > >> From my captured ddb run: >> cpuid = 3 >> curthread = 0xc5e2f000: pid 23090 "filter" >> curpcb = 0xe6f90d90 >> fpcurthread = none >> idlethread = 0xc442daf0: pid 11 "idle: cpu3" >> APIC ID = 7 >> currentldt = 0x50 >> spin locks held: >> > > At http://www.freebsd.org/~jhb/gdb/ you can find my kgdb scripts. If you > source gdb6 you can run 'runtds' which will show you what each CPU is doing > (more or less) in ps-style output. > > >> I sure wish I could find the root cause of the hangs. On a hunch, I >> tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it has >> run 32 hours without a hang. It could just be coincidence, though... >> > > Ahhh, that actually could explain it perhaps. Do your CPUs support C2 or > higher sleep states for idle? You can try limiting it to only C1 (or disable > C1E in your BIOS if it has an option for that) to see if that fixes it. > > I don't think the CPUs support anything lower than C1 - there is no hw.acpi.cpu.cx_supported sysctl node, and hw.cpi.cpu.cx_lowest is C1. C1-Enhanced was already disabled in the BIOS, at least on the machine running amd64. 48 hours of runtime, and no hangs seen yet. I did reboot it this morning to check the sleep settings in the BIOS. Guy From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 16:21:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11396106566B; Fri, 27 Feb 2009 16:21:08 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CDDF28FC17; Fri, 27 Feb 2009 16:21:06 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 9DD0061AD; Fri, 27 Feb 2009 11:21:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1235751664; bh=pohDzxgQnBilal2nolePCz0heVh7L8hvplDqRt3p0aU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dO2CGg3iZ4mWvf7zJc9LaE/7QI9sHVtOrQ9+YwKqCiJRBfUgppGP4HfdUAEKizdPw XZlthfmjOQ3bexfpmk87asu1Gcc8kPHlz/7WC4+yKR4qHRkWvZqy280Dw3JwNnX DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=VeVFAdVbAhFhksE4UO9/FoPMuWkUJF/ChEmFMko4KGGKisEqhB9irLlW2u1utP++l yq+3nPrZcSxYy6hXI4zLUj2EKMGcacEn0H5/9GkpDJ4zCorOWRJirLQRcJOCCWf Message-ID: <49A812EC.8060408@protected-networks.net> Date: Fri, 27 Feb 2009 11:21:00 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090217) MIME-Version: 1.0 To: John Baldwin References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> In-Reply-To: <200902271026.15796.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:21:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Baldwin wrote: > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > >> And the message is cycled. The kernel does not boot despite >> vm.pmap.pg_ps_enabled value. > > This should now be fixed, apologies for the breakage. :( What are the benefits and/or impacts of enabling this? Is there anything to be gained with respect to cache and/or TLB utilization in allowing entry promotion through a reduced "footprint" or similar? How much does this depend on architecture, say, e.g. Core-2 Duo vs. Pentium? I note that it is not enabled by default in -current either - just curious, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmoEuwACgkQQv9rrgRC1JKTcQCfQwKq1MuiwSJcNEaVWsJJZb+D 3oQAoJdM7WxgBi3YOUuV45D72sGcm/YX =0Osn -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 16:28:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A10D1065675; Fri, 27 Feb 2009 16:28:28 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8BC8FC29; Fri, 27 Feb 2009 16:28:28 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id CB6D12A4CF3; Fri, 27 Feb 2009 11:28:27 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 27 Feb 2009 11:28:27 -0500 X-Sasl-enc: yo+yq6f2WoE3xfRaghkhMJuvSAfR2h+VoUIPn6Oa4/CY 1235752107 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3CC3D2D020; Fri, 27 Feb 2009 11:28:27 -0500 (EST) Message-ID: <49A814B6.4090107@incunabulum.net> Date: Fri, 27 Feb 2009 16:28:38 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Baldwin References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> In-Reply-To: <200902271026.15796.jhb@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:28:33 -0000 John Baldwin wrote: > This should now be fixed, apologies for the breakage. : +1, appears to be fixed. thank you for the prompt fix! From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 16:30:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A585510656DE for ; Fri, 27 Feb 2009 16:30:09 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5063E8FC13 for ; Fri, 27 Feb 2009 16:30:09 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 5BA0C131059; Fri, 27 Feb 2009 19:30:08 +0300 (MSK) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 0B4B4131038; Fri, 27 Feb 2009 19:30:08 +0300 (MSK) Date: Fri, 27 Feb 2009 19:26:25 +0300 From: Igor Sysoev To: John Baldwin Message-ID: <20090227162625.GO51952@rambler-co.ru> References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200902271026.15796.jhb@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 27022009 #1852655, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 7509 [Feb 27 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Method: white ip list X-SpamTest-Rate: 0 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:30:10 -0000 On Fri, Feb 27, 2009 at 10:26:15AM -0500, John Baldwin wrote: > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > > Is anyone able to boot kernel with recently merged superpage support ? > > I have csup'd world to > > *default date=2009.02.26.23.59.59 > > then rebuild world and kernel does not boot: > > > > FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 > > XXXXXXXXXXXXXXXXXXXXX > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor read data, page not present > > instruction pointer = 0x8:0xffffffff803b1d80 > > stack pointer = 0x10:0xffffffff80686ce0 > > frame pointer = 0x10:0xffffffff80686d00 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 0 () > > trap number = 12 > > panic: page fault > > cpuid = 0 > > > > And the message is cycled. The kernel does not boot despite > > vm.pmap.pg_ps_enabled value. > > This should now be fixed, apologies for the breakage. :( Thank you, your commit has fixed the bug. Now I have $sysctl vm.pmap.pde vm.pmap.pde.promotions: 518 vm.pmap.pde.p_failures: 4534 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 423 Does this mean that (518 - 423) * 2 = 190M are mapped via 2M pages ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 16:31:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD88E10656C4; Fri, 27 Feb 2009 16:31:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A69438FC32; Fri, 27 Feb 2009 16:31:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 19DA92A5E3C; Fri, 27 Feb 2009 11:31:08 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 27 Feb 2009 11:31:08 -0500 X-Sasl-enc: cc4hwT0ir8hFYwRxelGBYa5O2yFbXljCjU8Iddg34Ip5 1235752267 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0166A2D031; Fri, 27 Feb 2009 11:31:06 -0500 (EST) Message-ID: <49A81556.2040801@incunabulum.net> Date: Fri, 27 Feb 2009 16:31:18 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Noland References: <6B7ABE80-35AB-4C44-B5A4-200E10DCC3AC@airwired.net> <499D4ED5.4030808@earthlink.net> <499D7D32.1020909@andric.com> <1235067723.9871.41.camel@widget.2hip.net> <20090219211200.3cdb6a92@it.buh.tecnik93.com> In-Reply-To: <20090219211200.3cdb6a92@it.buh.tecnik93.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sclark46@earthlink.net, Dimitry Andric , Ion-Mihai Tetcu , freebsd-stable@freebsd.org Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:31:09 -0000 I can confirm that with 7-STABLE as of this writing, the USB problems with amd64 and Xorg appear to be fixed. The key requirements are a 7-STABLE tree from *now*, a fresh buildworld+buildkernel, and a forced rebuild of libpciaccess to pick up PCIOCGETBAR. I can now run both scanpci and Xorg without seeing the loss of USB functionality from before. Thanks to jhb@ and rnoland@ for backporting the fixes! cheers, BMS From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 16:43:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33538106564A for ; Fri, 27 Feb 2009 16:43:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 037DD8FC17 for ; Fri, 27 Feb 2009 16:43:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id A16F946B59; Fri, 27 Feb 2009 11:43:14 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1RGh8fT052712; Fri, 27 Feb 2009 11:43:08 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Michael Butler Date: Fri, 27 Feb 2009 11:42:59 -0500 User-Agent: KMail/1.9.7 References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> <49A812EC.8060408@protected-networks.net> In-Reply-To: <49A812EC.8060408@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902271143.00094.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 27 Feb 2009 11:43:08 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9054/Fri Feb 27 04:02:52 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 16:43:15 -0000 On Friday 27 February 2009 11:21:00 am Michael Butler wrote: > John Baldwin wrote: > > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > > > >> And the message is cycled. The kernel does not boot despite > >> vm.pmap.pg_ps_enabled value. > > > > This should now be fixed, apologies for the breakage. :( > > What are the benefits and/or impacts of enabling this? > > Is there anything to be gained with respect to cache and/or TLB > utilization in allowing entry promotion through a reduced "footprint" or > similar? How much does this depend on architecture, say, e.g. Core-2 Duo > vs. Pentium? Yes there are gains due to what you mention, but it does depend on the specific processor and specifically the how it manages entries for large pages in its TLB (some processsors have separate TLB entries for large pages and have very few of them, others can store either a small or lage page in a single TLB slot, etc.). Alan knows far more of the details of this than I do. > I note that it is not enabled by default in -current either - just curious, Actually, it is enabled by default on amd64 in current. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 17:12:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E26F91065672 for ; Fri, 27 Feb 2009 17:12:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B18468FC15 for ; Fri, 27 Feb 2009 17:12:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 421CE46B43; Fri, 27 Feb 2009 12:12:28 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1RHCDak052923; Fri, 27 Feb 2009 12:12:22 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 27 Feb 2009 12:11:18 -0500 User-Agent: KMail/1.9.7 References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> <20090227162625.GO51952@rambler-co.ru> In-Reply-To: <20090227162625.GO51952@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902271211.18423.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 27 Feb 2009 12:12:22 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9054/Fri Feb 27 04:02:52 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:12:29 -0000 On Friday 27 February 2009 11:26:25 am Igor Sysoev wrote: > On Fri, Feb 27, 2009 at 10:26:15AM -0500, John Baldwin wrote: > > > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > > > Is anyone able to boot kernel with recently merged superpage support ? > > > I have csup'd world to > > > *default date=2009.02.26.23.59.59 > > > then rebuild world and kernel does not boot: > > > > > > FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 > > > XXXXXXXXXXXXXXXXXXXXX > > > kernel trap 12 with interrupts disabled > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x0 > > > fault code = supervisor read data, page not present > > > instruction pointer = 0x8:0xffffffff803b1d80 > > > stack pointer = 0x10:0xffffffff80686ce0 > > > frame pointer = 0x10:0xffffffff80686d00 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = resume, IOPL = 0 > > > current process = 0 () > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > > > > And the message is cycled. The kernel does not boot despite > > > vm.pmap.pg_ps_enabled value. > > > > This should now be fixed, apologies for the breakage. :( > > Thank you, your commit has fixed the bug. > > Now I have > > $sysctl vm.pmap.pde > vm.pmap.pde.promotions: 518 > vm.pmap.pde.p_failures: 4534 > vm.pmap.pde.mappings: 0 > vm.pmap.pde.demotions: 423 > > Does this mean that (518 - 423) * 2 = 190M are mapped via 2M pages ? I don't think that includes the direct map which uses 2M pages. I think your conclusion is correct, but alc@ would know for sure. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 18:00:41 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98C0106564A for ; Fri, 27 Feb 2009 18:00:41 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 90AF68FC0A for ; Fri, 27 Feb 2009 18:00:41 +0000 (UTC) (envelope-from ross.penner@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so813359yxl.13 for ; Fri, 27 Feb 2009 10:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Klqx+idYg2ppQSMUxVgvMmnrmFEqyZji0UbBIGckmyk=; b=pBadqktbDIUjYcgUCAoh7HsLI7B+aCQm1LKPyQa0E6rlw2W/S26QcXaslGRgzxiNrq VUsQpXsN9gX8CVlhv6mbwskFYpPrlfSmE/y6rN5pTnqv9qbeSWNLEEFP3P1/j/RDUrea 57ZYRkfFClryc0OWjfSuQS+8jrHF+bhHmtHvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dEI4QpbCtV1LrCU+C6mUJfwGh+TdStrooy+ahzTXq8xbwT1aG/G/ztgl9CWGdN329d ljXGwPJu31J7Fb4uf78AyWMGs7bF2pTPqvA0PNby9gFPrIbdKarOOKR4MB12NhLOKtQP +V3j+f7HogJS701B6uxf3DTXnsZOY+YfPZWwk= MIME-Version: 1.0 Received: by 10.90.89.18 with SMTP id m18mr100062agb.102.1235757634420; Fri, 27 Feb 2009 10:00:34 -0800 (PST) In-Reply-To: <3a142e750902270346m4358ad19p9883e6a69bda9b01@mail.gmail.com> References: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> <3a142e750902270346m4358ad19p9883e6a69bda9b01@mail.gmail.com> Date: Fri, 27 Feb 2009 10:00:34 -0800 Message-ID: From: Ross Penner To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:00:42 -0000 On Fri, Feb 27, 2009 at 3:46 AM, Paul B. Mahol wrote: > On 2/27/09, Ross Penner wrote: >> Perhaps, but I rarely run Xorg. I use the machine as a gateway for our >> network in the house. I've noticed it most often when under a network >> load but that might not be a real correlation. >> >> On Thu, Feb 26, 2009 at 2:47 PM, Paul B. Mahol wrote: >>> On 2/26/09, Ross Penner wrote: >>>> Hi, >>>> >>>> When I enable powerd, it is only but a matter of time before my >>>> machine will lock up completely. I've had this problem since I've >>>> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any >>>> problems. I doesn't seem to create a dump so I've had no luck on that >>>> end. I'm quite perplexed on how to proceed to help get this problem >>>> documented so it can be fixed. >>>> >>>> #uname -a >>>> FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 >>>> 00:38:44 PST 2009 >>>> ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 =A0i386 >>>> >>>> Is there anything else I con provide that would be of assistance? >>> >>> I'm aware of livelock between syscons and powerd which is not trivial t= o >>> reproduce (at least for me). > > The locks happens for me only if kernel prints something on console while > something other is being printed on vtys. > So it looks like your problem is not related to syscons bugs. > > -- > Paul Well, it might not actually be that far off. When I have powerd enabled, I frequently get a message on the console about 'vge watchdog timeout' Does anybody have any ideas on how to try and fix this issue? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 18:39:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68B8A1065679 for ; Fri, 27 Feb 2009 18:39:34 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9CA8FC16 for ; Fri, 27 Feb 2009 18:39:33 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so824688yxl.13 for ; Fri, 27 Feb 2009 10:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9RJM7uEfdA7BA8OGPm8elxK156gjXjRkhgwFGSLw3kY=; b=wFmFIVtr+hzXg4ZWe3GDey2Cw9gsfcNdnKXobXqTeKAcg4TCxTdMRBl05CNGAl4k9W D8AkR29E6OCnNBpFOmZ5PfEHdyQh16qQuso8JaKqFQ0drIBmHFIQYKkCjnSdNUxqZdX3 gSaEZWAPj6kA1kzpU5R/iBx3d9s9GcVC4xeAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=bopFZalMP2+CACu69r3IpO+Emijg8uiOcznpwKnH5Or+2Oid184dpYiuIfzt7RJhOj JZCUpRxUYf+h602daIMCs6DIUDmLi104+P7hZ/sb2UhQQFNa5yv7srIa9apN5FEC+qid ABffavXhXJLwqEmtTJgVpw4RLvpvYj4xgPubU= MIME-Version: 1.0 Received: by 10.150.122.18 with SMTP id u18mr4407643ybc.20.1235758279046; Fri, 27 Feb 2009 10:11:19 -0800 (PST) In-Reply-To: <200902271211.18423.jhb@freebsd.org> References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> <20090227162625.GO51952@rambler-co.ru> <200902271211.18423.jhb@freebsd.org> Date: Fri, 27 Feb 2009 12:11:19 -0600 Message-ID: From: Alan Cox To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:39:35 -0000 On Fri, Feb 27, 2009 at 11:11 AM, John Baldwin wrote: > On Friday 27 February 2009 11:26:25 am Igor Sysoev wrote: > > On Fri, Feb 27, 2009 at 10:26:15AM -0500, John Baldwin wrote: > > > > > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > > > > Is anyone able to boot kernel with recently merged superpage support > ? > > > > I have csup'd world to > > > > *default date=2009.02.26.23.59.59 > > > > then rebuild world and kernel does not boot: > > > > > > > > FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 > > > > XXXXXXXXXXXXXXXXXXXXX > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x0 > > > > fault code = supervisor read data, page not present > > > > instruction pointer = 0x8:0xffffffff803b1d80 > > > > stack pointer = 0x10:0xffffffff80686ce0 > > > > frame pointer = 0x10:0xffffffff80686d00 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = resume, IOPL = 0 > > > > current process = 0 () > > > > trap number = 12 > > > > panic: page fault > > > > cpuid = 0 > > > > > > > > And the message is cycled. The kernel does not boot despite > > > > vm.pmap.pg_ps_enabled value. > > > > > > This should now be fixed, apologies for the breakage. :( > > > > Thank you, your commit has fixed the bug. > > > > Now I have > > > > $sysctl vm.pmap.pde > > vm.pmap.pde.promotions: 518 > > vm.pmap.pde.p_failures: 4534 > > vm.pmap.pde.mappings: 0 > > vm.pmap.pde.demotions: 423 > > > > Does this mean that (518 - 423) * 2 = 190M are mapped via 2M pages ? > > I don't think that includes the direct map which uses 2M pages. I think > your > conclusion is correct, but alc@ would know for sure. > > -- > John Baldwin > _______________________________________________ > 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" > These counts are cumulative. So, they don't really provide you with an instantaneous number of the active 2MB page mappings. Moreover, when a 2MB page mapping is destroyed in its entirety, for example, when exit()ing a process, that does not trigger a demotion. In other words, a promoted 2MB page mapping can cease to exist without a demotion occurring. You are correct that in RELENG_7 these counts don't say anything about the direct map. Alan From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 18:49:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 957B51065677; Fri, 27 Feb 2009 18:49:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 540298FC1F; Fri, 27 Feb 2009 18:49:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1RIn6bp049876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 10:49:06 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49A835A2.3050002@freebsd.org> Date: Fri, 27 Feb 2009 10:49:06 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: Nathan Butcher , freebsd-stable@freebsd.org, Weongyo Jeong Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:49:07 -0000 Bengt Ahlgren wrote: > Weongyo Jeong writes: > > >> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >> >>> Bengt Ahlgren wrote: >>> >>>> Weongyo Jeong writes: >>>> >>>> >>>>> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote: >>>>> >>>>> >>>>>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor. >>>>>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1 >>>>>> >>>>>> Typically, It works for a while until eventually it stalls data >>>>>> transfers completely. It always seems to do this after an unspecified >>>>>> amount of time. >>>>>> >>>>>> I know the hardware isn't at fault because the device works fine under >>>>>> Linux. >>>>>> >>>>>> >>>>> Could you please check that `ifconfig -bgscan' disabling the >>>>> background scan helps your symptom? >>>>> >>>> The above sounds like the same problem as this: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html >>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>>> >>>> The problem is in the background scanning logic in sys/net80211. >>>> >>> I don't see how you come to this conclusion. ural is a totally >>> different driver than ath and so far as I can recall you never found the >>> cause for your problem w/ ath. Most of the usb wireless drivers do a >>> haphazard job of synchronizing async tasks like bg scan with the >>> foreground tx/rx processing. This can lead to firmware and/or usb >>> issues. ath does not have these issues but I am aware of at least one >>> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD). >>> >> I agree with sam because I saw some cases like stalls during background >> scanning that most of them I think it's caused by H/W miss-operation or >> miss-configuration by mistakes of driver. >> > > Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same > calls to net80211 which causes problems for ath. > > At line 1477, it has the same test as ath has to check for bg > scanning: > > if (ic->ic_flags & IEEE80211_F_SCAN) > ieee80211_cancel_scan(ic); > > That means that ieee80211_cancel_scan won't be called in the window > between when scan_next is run (which resets IEEE80211_F_SCAN), and > ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN > again). This is the same problem as ath has. > > But I can't find that ural calls ieee80211_pwrsave to queue packets if > a bgscan was running. It seems that it just merrily tries to send > packets despite scanning is going on. > > Please note that even though ieee80211_cancel_scan IS called, that > won't take effect until the next clock tick. So if the output routine > just carries on with sending a packet, it will do so in the middle of > the scan. This is something that should be fixed in net80211. > > So, I find that ural also suffers from the problem with the scanning > logic in net80211. > It appears RELENG_7's scanning code lacks the locking that's in HEAD to guard against the race you describe. Sam From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 18:49:11 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E15471065676; Fri, 27 Feb 2009 18:49:11 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 80D8F8FC24; Fri, 27 Feb 2009 18:49:11 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so829918ywt.13 for ; Fri, 27 Feb 2009 10:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7Zy3TriLO7BkdCoeo0Ttxpl5F9lKkXcDdFfmyF2PkVU=; b=noPKbuhVWPyMifTx2j8IZzKLbKg6wG7AogHoP4n1tHsfF4xeXNc86M9hikYKiQZa0P NaRUFTEQtVsYEt7G9S1D8ulJWgdYuDXpW+lOjkGd81YGPI0dXWrr4H+5eEDPeWnimuk8 tdkb9jGWdC+E9ajBTXucnVxdCb+qlnWaJGuBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=HQhNx6ms1nUkJvA7hW/hLfYDBUklQHa3HDV1VsDu9Iw1CuzKXZeobCQ/f7LDAkztGA tEzcZAgkr2SFsKgG5RGWSE71bp87I0Z3dFS7QpwCm1GVlW4z6xkGSbb9AMbE6mhKbPkb 9kgloRveSBI3GBtPldJe1vtH3nDeDai77WhqM= MIME-Version: 1.0 Received: by 10.151.106.7 with SMTP id i7mr4461909ybm.14.1235760550862; Fri, 27 Feb 2009 10:49:10 -0800 (PST) In-Reply-To: <200902271143.00094.jhb@freebsd.org> References: <20090227130830.GI51952@rambler-co.ru> <200902271026.15796.jhb@freebsd.org> <49A812EC.8060408@protected-networks.net> <200902271143.00094.jhb@freebsd.org> Date: Fri, 27 Feb 2009 12:49:10 -0600 Message-ID: From: Alan Cox To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-STABLE does not boot after recent superpage support MFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:49:12 -0000 On Fri, Feb 27, 2009 at 10:42 AM, John Baldwin wrote: > On Friday 27 February 2009 11:21:00 am Michael Butler wrote: > > John Baldwin wrote: > > > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote: > > > > > >> And the message is cycled. The kernel does not boot despite > > >> vm.pmap.pg_ps_enabled value. > > > > > > This should now be fixed, apologies for the breakage. :( > > > > What are the benefits and/or impacts of enabling this? > > > > Is there anything to be gained with respect to cache and/or TLB > > utilization in allowing entry promotion through a reduced "footprint" or > > similar? How much does this depend on architecture, say, e.g. Core-2 Duo > > vs. Pentium? > > Yes there are gains due to what you mention, but it does depend on the > specific processor and specifically the how it manages entries for large > pages in its TLB (some processsors have separate TLB entries for large > pages > and have very few of them, others can store either a small or lage page in > a > single TLB slot, etc.). Alan knows far more of the details of this than I > do. > > > I note that it is not enabled by default in -current either - just > curious, > > Actually, it is enabled by default on amd64 in current. > > -- > John Baldwin > _______________________________________________ > 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" > The short answer is ... if you're running an amd64 kernel on a Pentium 4, Core 2, or tri- or quad-core Opteron/Phenom, enable promotion. Your results with other amd64-compatible processors, single- and dual-core Athlon/Opteron and Atom, will be application dependent. You'll win some and you'll lose some. For a longer answer with data and figures, take a look at this paper: http://ft.ornl.gov/pubs-archive/ispass-final-csmd.pdf That said, there are secondary benefits to enabling large page support that have nothing to do with the TLB, specifically, it makes fork()ing and exit()ing large address spaces cheaper. Regards, Alan From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 19:07:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFB21065675 for ; Fri, 27 Feb 2009 19:07:39 +0000 (UTC) (envelope-from afriedman@drsns.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 445558FC15 for ; Fri, 27 Feb 2009 19:07:39 +0000 (UTC) (envelope-from afriedman@drsns.com) Received: by qw-out-2122.google.com with SMTP id 3so1201791qwe.7 for ; Fri, 27 Feb 2009 11:07:38 -0800 (PST) Received: by 10.229.74.85 with SMTP id t21mr2044067qcj.45.1235759969477; Fri, 27 Feb 2009 10:39:29 -0800 (PST) Received: from aharon-mac.friedman.net (rrcs-71-41-74-141.se.biz.rr.com [71.41.74.141]) by mx.google.com with ESMTPS id 6sm10850469yxg.6.2009.02.27.10.39.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 10:39:28 -0800 (PST) Message-Id: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> From: "Dr. Aharon Friedman" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 13:39:25 -0500 X-Mailer: Apple Mail (2.930.3) Subject: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:07:39 -0000 I have been trying to set up a zfs root file system on 7.1. It requires the loader gptzfsboot, which is in -CURRENT. I have tried to import it to 7.1. Before I delve into it. Has somebody already done it? Aharon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 20:10:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A78F1065676 for ; Fri, 27 Feb 2009 20:10:20 +0000 (UTC) (envelope-from bill@mi.celestial.com) Received: from dorsai-02.celestial.com (dorsai-02.celestial.com [192.136.111.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6418FC19 for ; Fri, 27 Feb 2009 20:10:20 +0000 (UTC) (envelope-from bill@mi.celestial.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by dorsai-02.celestial.com (Postfix) with ESMTP id 4E3E9206C90D for ; Fri, 27 Feb 2009 11:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at celestial.com Received: from dorsai-02.celestial.com ([127.0.0.1]) by localhost (dorsai-02.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4FDEOERf4BmR for ; Fri, 27 Feb 2009 11:47:13 -0800 (PST) Received: from ayn.mi.celestial.com (hayek.celestial.com [192.136.111.12]) by dorsai-02.celestial.com (Postfix) with ESMTP id 1AA2E206BE0A for ; Fri, 27 Feb 2009 11:47:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ayn.mi.celestial.com (Postfix) with ESMTP id D67F168BBC5C8; Fri, 27 Feb 2009 11:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at mi.celestial.com Received: from ayn.mi.celestial.com ([127.0.0.1]) by localhost (ayn.mi.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hLBwXwRvDm5S; Fri, 27 Feb 2009 11:47:12 -0800 (PST) Received: by ayn.mi.celestial.com (Postfix, from userid 203) id B899668BBC566; Fri, 27 Feb 2009 11:47:12 -0800 (PST) Date: Fri, 27 Feb 2009 11:47:12 -0800 From: Bill Campbell To: freebsd-stable@freebsd.org Message-ID: <20090227194712.GB25297@ayn.mi.celestial.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> User-Agent: Mutt/1.5.19 OpenPKG/% (2009-01-05) Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@celestial.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:10:20 -0000 On Fri, Feb 27, 2009, Dr. Aharon Friedman wrote: > I have been trying to set up a zfs root file system on 7.1. It requires > the loader gptzfsboot, which is in -CURRENT. I have tried to import it > to 7.1. Before I delve into it. Has somebody already done it? As a general rule, I avoid using anything but a system's standard file system for the root/boot file system(s), using the more esoteric file systems for things mounted after boot. While it may feel nice to have nifty stuff, it can cause far more problems that it's worth. Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 ...I'm not one of those who think Bill Gates is the devil. I simply suspect that if Microsoft ever met up with the devil, it wouldn't need an interpreter. -- Nick Petreley From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 20:22:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D51B106566C for ; Fri, 27 Feb 2009 20:22:08 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 42F428FC08 for ; Fri, 27 Feb 2009 20:22:08 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id EFC5C2844E for ; Sat, 28 Feb 2009 04:22:06 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 49FF9EB8123; Sat, 28 Feb 2009 04:22:06 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id gG6fuS2ADdp7; Sat, 28 Feb 2009 04:22:01 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 27CF4EB67DC; Sat, 28 Feb 2009 04:21:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=i+91m0IFFU+/p2dX1FxGLrB/8DxN3YYVUx83WJAOHLyb/PYhnu6357DiohhZSqP54 6kxGM/dMBacwAH5lSSb5w== Message-ID: <49A84B63.5080903@delphij.net> Date: Fri, 27 Feb 2009 12:21:55 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090217) MIME-Version: 1.0 To: "Dr. Aharon Friedman" References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> In-Reply-To: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:22:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dr. Aharon Friedman wrote: > I have been trying to set up a zfs root file system on 7.1. It requires > the loader gptzfsboot, which is in -CURRENT. I have tried to import it > to 7.1. Before I delve into it. Has somebody already done it? I think this means you want to "boot" from ZFS, not only making it the / file system. Booting from ZFS would require some new code from -CURRENT tree (sys/cddl/boot, etc) and there is some limitations, e.g. it can't be used with RAID-Z volumes, etc. My personal suggestion is that you either use -CURRENT, or wait until a full MFC of ZFS v13, or use UFS /boot at this moment (note the fact that / can not be easily rolled back to previous state using ZFS's snapshot feature, and can not be easily switched between clones, use caution when working with the whole stuff). Note that, given that ZFS is more complicated than UFS, having it as / would make it harder when you got some problems and boot with LiveFS disc (the bright side is that, if you have mirrored volume as the boot volume, you get a better chance to survive a disk failure). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmoS2MACgkQi+vbBBjt66DggwCfQnEtZ++nSjAOB1pD+uQNxpYl 9pIAoIwXh6AK9d38B6ZL077NWXJpDhPV =ODQn -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 22:36:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E77106566C for ; Fri, 27 Feb 2009 22:36:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 55AB28FC12 for ; Fri, 27 Feb 2009 22:36:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id n1RMaHtj060581; Fri, 27 Feb 2009 15:36:17 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id n1RMaH1g060578; Fri, 27 Feb 2009 15:36:17 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 27 Feb 2009 15:36:17 -0700 (MST) From: Warren Block To: Doug Barton In-Reply-To: <49A4BC40.1080301@FreeBSD.org> Message-ID: References: <49A4BC40.1080301@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (wonkity.com [127.0.0.1]); Fri, 27 Feb 2009 15:36:17 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: Old /etc files back, or cvs error? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:36:19 -0000 On Tue, 24 Feb 2009, Doug Barton wrote: > Warren Block wrote: > >> mergemaster adds a *lot* of old files in /etc that were not there in >> 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a >> bunch of bluetooth files and /etc/isdn/*. > > That is definitely not the outcome you should have ended up with. I should have been more careful in watching what was going on. It wasn't adding files, just "updating" files that only differed in version strings. A test system showed that as of now, there's somewhere around 325 files in /etc like that. That's not counting files which will probably be different like /etc/master.passwd and /etc/group, or the sendmail files which are customized with "built by" messages. (The differing file version strings are due to the svn to cvs export, as explained by Erik Trulsson.) > If that doesn't work, please script your mergemaster session and send > us the output. I did save both a full session and a cleaned list of files from a test system built with 7.1-RELEASE and updated to 7-STABLE: http://www.wonkity.com/~wblock/freebsd-7-stable/ Only after manually creating that list of files did it occur to me that there ought to be a way to skip files that differ only in version strings, and that mergemaster should have that. And *then* I finally checked the man page for mergemaster, where the mysterious -U option is described. mergemaster -U works fine. Had I only been lazy enough to look it up beforehand... The mergemaster man page doesn't tell how mergemaster detects "files that have not been user modified", so I'm not sure how safe -U really is. If it's safe for everyday users, then the second mergemaster step in the standard updating procedure in the Handbook should include the -U. The svn/cvs/version string thing sure looks like a bug, but no doubt fixing it is easier said than done. -Warren Block * Rapid City, South Dakota USA From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 01:05:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217F2106564A for ; Sat, 28 Feb 2009 01:05:24 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f166.google.com (mail-ew0-f166.google.com [209.85.219.166]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0A98FC08 for ; Sat, 28 Feb 2009 01:05:23 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy10 with SMTP id 10so1439584ewy.43 for ; Fri, 27 Feb 2009 17:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4RvcKsdWlt6mZGL1zdhjcx6+sc5yUmOGwsQzvrSBdPE=; b=mmsEXH8bS346xKffKmtNnjQjfXAtNvPKI3MDG/1IGeFaJHk/YLOitiUJyA9SzOz5vS mzTkeIxQRe3MaNcLx4G4Xi3xgvFmmj73ZKd7UPr3SPV1/Hl2REQ66zAH1bs9n+1brswE QtYz0tPQDGIW6cdhPyUjFMHYplXUlmMQMBJfw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B9xli53LRKNZhgErPNms2Zb7KhEOU9kOt33/vTEkhHukogHALbrjGxXghozTghDkJT MCh4caHWAPbpysysC1hMnfZO7lH6mBvO/D6GKfm0oB1Ias/8g43hUVeCuuq4NMUd7C9j u7Wb7LsvjDu9iWs8YsYBcicpHIkIUBbqn/3pA= MIME-Version: 1.0 Received: by 10.210.89.4 with SMTP id m4mr900580ebb.53.1235783122593; Fri, 27 Feb 2009 17:05:22 -0800 (PST) In-Reply-To: References: <3a142e750902261447k7cac4eb6m457726bc1f4b23d3@mail.gmail.com> <3a142e750902270346m4358ad19p9883e6a69bda9b01@mail.gmail.com> Date: Sat, 28 Feb 2009 02:05:22 +0100 Message-ID: <3a142e750902271705n754aa003v7aa756cff2b54daf@mail.gmail.com> From: "Paul B. Mahol" To: Ross Penner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: powerd causing crash on Mini-ITX EN1200 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 01:05:24 -0000 On 2/27/09, Ross Penner wrote: > On Fri, Feb 27, 2009 at 3:46 AM, Paul B. Mahol wrote: >> On 2/27/09, Ross Penner wrote: >>> Perhaps, but I rarely run Xorg. I use the machine as a gateway for our >>> network in the house. I've noticed it most often when under a network >>> load but that might not be a real correlation. >>> >>> On Thu, Feb 26, 2009 at 2:47 PM, Paul B. Mahol wrote: >>>> On 2/26/09, Ross Penner wrote: >>>>> Hi, >>>>> >>>>> When I enable powerd, it is only but a matter of time before my >>>>> machine will lock up completely. I've had this problem since I've >>>>> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any >>>>> problems. I doesn't seem to create a dump so I've had no luck on that >>>>> end. I'm quite perplexed on how to proceed to help get this problem >>>>> documented so it can be fixed. >>>>> >>>>> #uname -a >>>>> FreeBSD rosbox.dyndns.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 26 >>>>> 00:38:44 PST 2009 >>>>> ross@rosbox.dyndns.org:/usr/obj/usr/src/sys/MYKERNEL7 i386 >>>>> >>>>> Is there anything else I con provide that would be of assistance? >>>> >>>> I'm aware of livelock between syscons and powerd which is not trivial >>>> to >>>> reproduce (at least for me). >> >> The locks happens for me only if kernel prints something on console while >> something other is being printed on vtys. >> So it looks like your problem is not related to syscons bugs. >> >> -- >> Paul > > Well, it might not actually be that far off. When I have powerd > enabled, I frequently get a message on the console about 'vge watchdog > timeout' I got that similar one when using "powerd -b min" and transferring big file with ndis vap configured in adhoc mode. Probably I was just lucky that I used min instead of (h)adp. > Does anybody have any ideas on how to try and fix this issue? One nasty fix would be disabling kernel messages on console. I never tested if it actually works, or perhaps I did but forgot about it ;) : echo "kern.consmute=1" >> /boot/sysctl.conf Another, better one would be to make syscons giant free, perhaps rewriting it from scratch .... -- Paul From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 03:32:29 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 050EF1065672 for ; Sat, 28 Feb 2009 03:32:29 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7222E8FC17 for ; Sat, 28 Feb 2009 03:32:28 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n1S3LFWf018623 for ; Fri, 27 Feb 2009 19:21:15 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n1S3LFxR018622; Fri, 27 Feb 2009 19:21:15 -0800 (PST) Date: Fri, 27 Feb 2009 19:21:15 -0800 (PST) From: Matthew Dillon Message-Id: <200902280321.n1S3LFxR018622@apollo.backplane.com> To: freebsd-stable@freebsd.org References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 03:32:29 -0000 My experience with one of our people trying to do the same thing w/ HAMMER... we got it working, but it is not necessarily cleaner. I'd rather just boot from a small UFS /boot partition on 'a' (256M or 512M), followed by swap on 'b', followed by the big-ass root partition on 'd' using your favorite filesystem. The boot code already pretty much handles this state of affairs, one only needs: (1) To partition it this way. (2) Add line to /boot/loader.conf pointing the kernel at the actual root, e.g. (in my case): vfs.root.mountfrom="hammer:ad6s1d" (3) Adjust sysctl kern.bootfile in e.g. /etc/sysctl.conf. Since the boot loader thinks the kernel is on / instead of /boot (because /boot is the root from the point of view of the bootloader), it might set this to "/kernel" instead of "/boot/kernel". So you may have to override it to make crash dumps and name lists work properly. (4) Add a mount for the little /boot partition in /etc/fstab. Trying to create one large root on 'a' puts the default spot for swap on 'b' at the end of the disk instead of near the beginning. The end of the disk (closer to the spindle) is a bad place for swap. Having a small /boot partition there instead retains the ordering and puts the swap where it is expected to be. # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad6s1d 193888256 1662976 192225280 1% / /dev/ad6s1a 257998 110896 126464 47% /boot -- In anycase, if RAID is an issue the loader could always be adjusted to look for a boot partition on multiple disks. One could then have a /boot on two independant disks, or even operate it as a soft-raid-mirror. It seems less of an issue these days since someone with that sort of requirement who isn't already net-booting can just pop in a SSD for booting which will have approximately the same or better MTBF as the motherboard electronics. The problem we face with HAMMER is related to the boot loader not being able to run the UNDO buffer (yet), so it might not be able to find the kernel after a crash. That and the inconvenient place swap ends up at. -Matt From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 04:43:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73D861065670 for ; Sat, 28 Feb 2009 04:43:04 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 2A98F8FC15 for ; Sat, 28 Feb 2009 04:43:03 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n1S4Cn4W089895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Feb 2009 22:12:50 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n1S4Cmel033568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Feb 2009 22:12:49 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n1S4Clnl033554; Fri, 27 Feb 2009 22:12:47 -0600 (CST) (envelope-from dan) Date: Fri, 27 Feb 2009 22:12:47 -0600 From: Dan Nelson To: Matthew Dillon Message-ID: <20090228041247.GJ45976@dan.emsphone.com> References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> <200902280321.n1S3LFxR018622@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902280321.n1S3LFxR018622@apollo.backplane.com> X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Fri, 27 Feb 2009 22:12:50 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 04:43:04 -0000 In the last episode (Feb 27), Matthew Dillon said: > My experience with one of our people trying to do the same thing w/ > HAMMER... we got it working, but it is not necessarily cleaner. > > I'd rather just boot from a small UFS /boot partition on 'a' (256M or > 512M), followed by swap on 'b', followed by the big-ass root partition on > 'd' using your favorite filesystem. > > The boot code already pretty much handles this state of affairs, one only > needs: > > (1) To partition it this way. > > (2) Add line to /boot/loader.conf pointing the kernel at the actual root, > e.g. (in my case): > > vfs.root.mountfrom="hammer:ad6s1d" > > (3) Adjust sysctl kern.bootfile in e.g. /etc/sysctl.conf. Since the > boot loader thinks the kernel is on / instead of /boot (because > /boot is the root from the point of view of the bootloader), it might > set this to "/kernel" instead of "/boot/kernel". So you may have to > override it to make crash dumps and name lists work properly. > > (4) Add a mount for the little /boot partition in /etc/fstab. I find it better (and easier to recover if something bad happens) if you create a /.boot filesystem with /boot and copies of /{bin,sbin,lib,libexec,etc} from your root partition, then symlink /boot in your root partition to /.boot/boot. That way you have a minimal system with recovery tools in case your non-UFS root has problems of any sort, and /boot always points to what you (and makefiles) think it should. If you have root on mirrored disks, you can gmirror /.boot too. Works great for ZFS; should work for HAMMER. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 06:47:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F053106564A for ; Sat, 28 Feb 2009 06:47:15 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id E6FA58FC14 for ; Sat, 28 Feb 2009 06:47:14 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-228-87.phil.east.verizon.net [70.20.228.87]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 67E2D3FBC8 for ; Sat, 28 Feb 2009 15:47:13 +0900 (JST) Date: Sat, 28 Feb 2009 01:47:07 -0500 From: Yoshihiro Ota To: freebsd-stable@freebsd.org Message-Id: <20090228014707.6129a1bb.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Question about disk schedulers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 06:47:15 -0000 Hi, Luigi and Fabio: I have a question about the GEOM disk scheduler you announed a while ago. http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html Can you tell me how does the scheduler interact with gjournal? Do you expect to improve response time even if used together with gjounral or to interfere each other? As I only had a journaled partition available for an experiment, I tried this combination on 7.1-RELEASE but it paniced 4 times out of 5 at attempts as soon as I mounted. Thanks, Hiro From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 07:00:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B621065670 for ; Sat, 28 Feb 2009 07:00:39 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 43B4E8FC1C for ; Sat, 28 Feb 2009 07:00:39 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-228-87.phil.east.verizon.net [70.20.228.87]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 648B767DF0; Sat, 28 Feb 2009 16:00:36 +0900 (JST) Date: Sat, 28 Feb 2009 02:00:30 -0500 From: Yoshihiro Ota To: Matthew Dillon Message-Id: <20090228020030.b9aa657c.ota@j.email.ne.jp> In-Reply-To: <200902280321.n1S3LFxR018622@apollo.backplane.com> References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> <200902280321.n1S3LFxR018622@apollo.backplane.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 07:00:39 -0000 On Fri, 27 Feb 2009 19:21:15 -0800 (PST) Matthew Dillon wrote: > My experience with one of our people trying to do the same thing > w/ HAMMER... we got it working, but it is not necessarily cleaner. Does that mean someone ported HAMMER to FreeBSD or someone did it on DragonFlyBSD? Thanks, Hiro From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 07:47:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF195106564A for ; Sat, 28 Feb 2009 07:47:28 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id ED6818FC16 for ; Sat, 28 Feb 2009 07:47:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C89B7456AB; Sat, 28 Feb 2009 08:19:17 +0100 (CET) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8615545683; Sat, 28 Feb 2009 08:19:11 +0100 (CET) Date: Sat, 28 Feb 2009 08:19:45 +0100 From: Pawel Jakub Dawidek To: Matthew Dillon Message-ID: <20090228071945.GA2314@garage.freebsd.pl> References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> <200902280321.n1S3LFxR018622@apollo.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <200902280321.n1S3LFxR018622@apollo.backplane.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 07:47:29 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 27, 2009 at 07:21:15PM -0800, Matthew Dillon wrote: > My experience with one of our people trying to do the same thing=20 > w/ HAMMER... we got it working, but it is not necessarily cleaner. >=20 > I'd rather just boot from a small UFS /boot partition on 'a' (256M > or 512M), followed by swap on 'b', followed by the big-ass root > partition on 'd' using your favorite filesystem. That's what I do on almost all of my company's servers. Except for... > The boot code already pretty much handles this state of affairs, one = only > needs: >=20 > (1) To partition it this way. >=20 > (2) Add line to /boot/loader.conf pointing the kernel at the actual r= oot, > e.g. (in my case): >=20 > vfs.root.mountfrom=3D"hammer:ad6s1d" This is not needed if you have etc/fstab with this one entry on your boot partition. > (3) Adjust sysctl kern.bootfile in e.g. /etc/sysctl.conf. Since the > boot loader thinks the kernel is on / instead of /boot (because > /boot is the root from the point of view of the bootloader), > it might set this to "/kernel" instead of "/boot/kernel". So > you may have to override it to make crash dumps and name lists > work properly. This is also not needed. My boot partition has boot/ and etc/ directories and I mount it under /bootdir. Then I create symlink /boot -> bootdir/boot. > (4) Add a mount for the little /boot partition in /etc/fstab. >=20 > Trying to create one large root on 'a' puts the default spot for swap > on 'b' at the end of the disk instead of near the beginning. The end > of the disk (closer to the spindle) is a bad place for swap. Having > a small /boot partition there instead retains the ordering and puts t= he > swap where it is expected to be. >=20 > # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad6s1d 193888256 1662976 192225280 1% / > /dev/ad6s1a 257998 110896 126464 47% /boot >=20 > -- >=20 > In anycase, if RAID is an issue the loader could always be adjusted to > look for a boot partition on multiple disks. One could then have a /= boot > on two independant disks, or even operate it as a soft-raid-mirror. = It > seems less of an issue these days since someone with that sort of > requirement who isn't already net-booting can just pop in a SSD for > booting which will have approximately the same or better MTBF as the > motherboard electronics. My 'a' (boot) and 'b' (swap) partitions are mirrored using gmirror. For example: puppet:root:~# mount -t ufs,zfs system/root on / (zfs, local, noatime) /dev/mirror/boot on /bootdir (ufs, local, noatime) system/jails on /jails (zfs, local, noatime) system/tmp on /tmp (zfs, local, noatime, nosuid) system/usr on /usr (zfs, local, noatime) system/home on /usr/home (zfs, local, noatime, nosuid) system/home/pjd on /usr/home/pjd (zfs, local, noatime, nosuid) system/usr/obj on /usr/obj (zfs, local, noatime) system/usr/ports on /usr/ports (zfs, local, noatime) system/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) system/usr/share on /usr/share (zfs, local, noatime) system/usr/src on /usr/src (zfs, local, noatime) system/var/log on /var/log (zfs, local, noatime) system/var/tmp on /var/tmp (zfs, local, noatime, nosuid) puppet:root:~# swapctl -l Device: 1024-blocks Used: /dev/mirror/swap.eli 4194300 0 Some file systems like /tmp, /usr/src, /usr/ports, /usr/share, /var/log and /var/tmp are compressed. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJqOWRForvXbEpPzQRAhgUAKCZobfdx5kPgOklIwIfSoMVuU9u3ACg43R7 kaAjRpkLU+1jQvllOfvGAkk= =Ii52 -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 14:25:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F87106566C for ; Sat, 28 Feb 2009 14:25:10 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1EDC18FC16 for ; Sat, 28 Feb 2009 14:25:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LdQ7j-0007HL-2K for freebsd-stable@freebsd.org; Sat, 28 Feb 2009 14:25:03 +0000 Received: from p5b205660.dip.t-dialin.net ([91.32.86.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Feb 2009 14:25:03 +0000 Received: from sperber by p5b205660.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Feb 2009 14:25:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Michael Sperber Date: Sat, 28 Feb 2009 14:13:10 +0100 Lines: 17 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b205660.dip.t-dialin.net User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b28 (darwin) Cancel-Lock: sha1:3/jheV92r+Y5oBLWrAfXhCI9hOM= Sender: news Subject: devd question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:25:10 -0000 I'm trying to make devd run an stty command whenever a USB serial device is attached. Unfortunately, $device-name is ucom[0-9] and the device names are /dev/cuaU[0-9] - how do I get the correct name in the device action? I haven't found a way to extract the number by itself, so I'm stuck with specifying a separate rule for each number, like so: attach 100 { device-name "ucom0"; action "stty -f /dev/cuaU0.init raw"; }; Help would be much appreciated! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 14:26:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE9DA1065689 for ; Sat, 28 Feb 2009 14:26:45 +0000 (UTC) (envelope-from lists@loveturtle.net) Received: from loveturtle.net (loveturtle.net [216.89.228.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEE18FC16 for ; Sat, 28 Feb 2009 14:26:45 +0000 (UTC) (envelope-from lists@loveturtle.net) Received: from localhost (localhost [127.0.0.1]) by loveturtle.net (Postfix) with ESMTP id BED8D6B337 for ; Sat, 28 Feb 2009 09:10:38 -0500 (EST) X-Virus-Scanned: amavisd-new at loveturtle.net Received: from loveturtle.net ([127.0.0.1]) by localhost (loveturtle.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Tq7-lRcDiMI for ; Sat, 28 Feb 2009 09:10:36 -0500 (EST) Received: from ramuh.loveturtle.net (ramuh.loveturtle.net [216.182.254.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by loveturtle.net (Postfix) with ESMTPSA id 2BA286B324 for ; Sat, 28 Feb 2009 09:10:36 -0500 (EST) Message-ID: <49A945D8.10000@loveturtle.net> Date: Sat, 28 Feb 2009 09:10:32 -0500 From: Dillon Kass User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> In-Reply-To: <49A84B63.5080903@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:26:48 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dr. Aharon Friedman wrote: > > (note the fact that > / can not be easily rolled back to previous state using ZFS's snapshot > feature, and can not be easily switched between clones I actually keep a full minimal install on my UFS /bootdisk slice (which i use geom mirror for) and then symlink /bootdisk/boot to /boot on the ZFS /. This way should I ever need to rollback ZFS / I can quickly change the vfs.root.mountfrom to /dev/mirror/gm0 and then have a base system living entirely on UFS. If you do it that way you can easily rollback your ZFS / should you need to and then just reboot back to the ZFS / when you're done. Cheers, Dillon From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 14:34:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E2501065670 for ; Sat, 28 Feb 2009 14:34:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id D6A5B8FC15 for ; Sat, 28 Feb 2009 14:34:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LdQHI-000Dhg-LC; Sat, 28 Feb 2009 16:34:56 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1SEYsss097242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 16:34:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1SEYskH051737; Sat, 28 Feb 2009 16:34:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1SEYrCd051736; Sat, 28 Feb 2009 16:34:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Feb 2009 16:34:53 +0200 From: Kostik Belousov To: Michael Sperber Message-ID: <20090228143453.GX41617@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HQLHrCACpVdwMl/9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LdQHI-000Dhg-LC 015c8a297e8dd6b7c31fdc4c890cc0dd X-Terabit: YES Cc: freebsd-stable@freebsd.org Subject: Re: devd question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:34:59 -0000 --HQLHrCACpVdwMl/9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote: >=20 > I'm trying to make devd run an stty command whenever a USB serial device > is attached. Unfortunately, $device-name is ucom[0-9] and the device > names are /dev/cuaU[0-9] - how do I get the correct name in the device > action? I haven't found a way to extract the number by itself, so I'm > stuck with specifying a separate rule for each number, like so: >=20 > attach 100 { > device-name "ucom0"; > action "stty -f /dev/cuaU0.init raw"; > }; >=20 > Help would be much appreciated! There are some other notifications that are send through devctl when cdev is created. They have system set to DEVFS, subsystem to CDEV, and type CREATE. The data is the /dev node name. I am not sure how to assign the action in the devd. --HQLHrCACpVdwMl/9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmpS40ACgkQC3+MBN1Mb4jWggCgpq+xfdHfoUpwdjachoOcP3Qv c5QAmwTodBWsoq8MclGpJrZbyBtM5Ha9 =6Swi -----END PGP SIGNATURE----- --HQLHrCACpVdwMl/9-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 16:18:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE819106564A for ; Sat, 28 Feb 2009 16:18:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id A37B98FC0A for ; Sat, 28 Feb 2009 16:18:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 10BA773098; Sat, 28 Feb 2009 17:23:03 +0100 (CET) Date: Sat, 28 Feb 2009 17:23:03 +0100 From: Luigi Rizzo To: Yoshihiro Ota Message-ID: <20090228162303.GA13685@onelab2.iet.unipi.it> References: <20090228014707.6129a1bb.ota@j.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228014707.6129a1bb.ota@j.email.ne.jp> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, fabio@gandalf.sssup.it Subject: Re: Question about disk schedulers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 16:18:09 -0000 On Sat, Feb 28, 2009 at 01:47:07AM -0500, Yoshihiro Ota wrote: > Hi, Luigi and Fabio: > > I have a question about the GEOM disk scheduler you announed a while ago. > http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html > > Can you tell me how does the scheduler interact with gjournal? > Do you expect to improve response time even if used together with gjounral > or to interfere each other? > > As I only had a journaled partition available for an experiment, I tried > this combination on 7.1-RELEASE but it paniced 4 times out of 5 at attempts > as soon as I mounted. Hi, a possible problem is that the scheduler uses the bio_caller1 field in the topmost request to store classification info -- there is no place to store the info in a standard 'bio' and changing the structure is rather intrusive. I see that gjournal.h has this comment: /* * Use bio_caller1 field as a pointer in queue. */ #define bio_next bio_caller1 so if gjournal is the top layer in the hierarchy there might be a conflict. Apart from adding a specific field to the struct bio (in the long term this is the way to go) perhaps one could try and add a gnop class on top of gjournal, so that would free the bio_caller1 in the topmost bio and prevent the panic. But thanks for the report, we will keep this in mind and in the next release (which should happen in a week or so) we will also add a patch or suggestion for handling this problem cheers luigi From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 18:06:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B6C10656F6 for ; Sat, 28 Feb 2009 18:06:40 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF1D8FC26 for ; Sat, 28 Feb 2009 18:06:40 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 5B53D171D40; Sat, 28 Feb 2009 08:06:39 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id D42E9153882; Sat, 28 Feb 2009 08:06:38 -1000 (HST) Date: Sat, 28 Feb 2009 08:06:38 -1000 From: Clifton Royston To: Matthew Dillon Message-ID: <20090228180637.GA26264@lava.net> Mail-Followup-To: Matthew Dillon , freebsd-stable@freebsd.org References: <4E614185-A54E-43B8-8C07-4BA901DE5861@drsns.com> <49A84B63.5080903@delphij.net> <200902280321.n1S3LFxR018622@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902280321.n1S3LFxR018622@apollo.backplane.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: ZFS root File System X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 18:06:43 -0000 On Fri, Feb 27, 2009 at 07:21:15PM -0800, Matthew Dillon wrote: > My experience with one of our people trying to do the same thing > w/ HAMMER... we got it working, but it is not necessarily cleaner. > > I'd rather just boot from a small UFS /boot partition on 'a' (256M > or 512M), followed by swap on 'b', followed by the big-ass root > partition on 'd' using your favorite filesystem. For those who want resilience, on FreeBSD you could also make that boot partition mirrored across drives with gmirror. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 22:31:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 003A5106564A for ; Sat, 28 Feb 2009 22:31:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id BA3638FC21 for ; Sat, 28 Feb 2009 22:31:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LdXhu-000MI9-CY for freebsd-stable@freebsd.org; Sat, 28 Feb 2009 22:30:54 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LdXhu-0007nK-8N for freebsd-stable@freebsd.org; Sat, 28 Feb 2009 22:30:54 +0000 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Sat, 28 Feb 2009 22:30:54 +0000 Subject: vm_thread_new: kstack allocation failed with vm.kmem_size="1536M" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 22:31:07 -0000 So, I have a farm of machines runnign 7.1/amd64, all of which have 16 gig of memory in them. This afternoon, as an experiment, I altered loader.conf to have these two lines in it: vm.kmem_size="1536M" vm.kmem_size_max="1536M" This is what I do on machines running ZFS - these machines are not, however running ZFS, and do not have the zfs module loaded. I just wanted to see if they would run OK with those kernel settings (as I may put ZFS on them in the future) I expected it to run fine, I just wanted to make sure. But after about an hour I started getting the message in the subject line, and the machines were unable to fork and needed to be reset. Explanation anyone ? This makes no sense to me - I have actually expanded the amount of memory available, so why is it now running out of stack space ?! The machines are running a very simple setup of apache, mysql and tomcat - and this runs fine with the kernel variables set as default. I am very puzzled. -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 28 23:01:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B7F1065688 for ; Sat, 28 Feb 2009 23:01:33 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1988FC31 for ; Sat, 28 Feb 2009 23:01:33 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n1SN1W8D098005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Feb 2009 17:01:32 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n1SN1Vvj029079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Feb 2009 17:01:32 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n1SN1UHg029078; Sat, 28 Feb 2009 17:01:30 -0600 (CST) (envelope-from dan) Date: Sat, 28 Feb 2009 17:01:30 -0600 From: Dan Nelson To: Pete French Message-ID: <20090228230127.GA3465@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sat, 28 Feb 2009 17:01:32 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-stable@freebsd.org Subject: Re: vm_thread_new: kstack allocation failed with vm.kmem_size="1536M" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 23:01:34 -0000 In the last episode (Feb 28), Pete French said: > So, I have a farm of machines runnign 7.1/amd64, all of which have 16 gig > of memory in them. This afternoon, as an experiment, I altered > loader.conf to have these two lines in it: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > > This is what I do on machines running ZFS - these machines are not, > however running ZFS, and do not have the zfs module loaded. I just wanted > to see if they would run OK with those kernel settings (as I may put ZFS > on them in the future) You've probably reduced kmem_size from the default. I don't set anything on my 6 GB amd64 system, and I get: $ sysctl vm.kmem_size vm.kmem_size_max vm.kmem_size: 2061496320 vm.kmem_size_max: 3865468109 I assume your 16GB system would default to even larger numbers. What values do you get without forcing anything in loader.conf? -- Dan Nelson dnelson@allantgroup.com