From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 07:36:26 2008 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 07ECD106564A for ; Sun, 16 Mar 2008 07:36:26 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 082028FC13 for ; Sun, 16 Mar 2008 07:36:25 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id 02DAD33D3E; Sun, 16 Mar 2008 00:36:16 -0700 (PDT) Date: Sun, 16 Mar 2008 00:36:16 -0700 From: Ulf Zimmermann To: Joe Koberg Message-ID: <20080316073616.GQ87650@evil.alameda.net> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D86A01.8070500@osoft.us> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-stable@freebsd.org, Johan Str?m Subject: Re: HP ProLiant DL360 G5 success stories? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 07:36:26 -0000 On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: > Johan Str?m wrote: > >But.. > >http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf seems > >to tell me that in basic mode I can only access BIOS (pre-OS) using the > >Remote Console feature, and that after POST I have to have the advanced > >licensed option? > > > > I don't do the purchasing and we get all Advanced iLO, so I will take > your word for it. The older generations supported text console (i have > a 360G2 that does so). We use the HP Management agents under Windows > for all SNMP reporting so I can't comment on the reporting method under > other OS's. iLO2 ActiveX based remote console (Integrated KVM) can still do text only console without license but it doesn't work too well IMHO. The Java based console is the same, text will work out license but graphics mode and that includes certain VESA text modes. Standard iLO gives the graphical console and virtual media. On Blade servers the graphical access and virtual media is included. And the Advanced license gives extra stuff like integration into AD for authentication afik. I have been running, at least until I had to roll out Linsux, FreeBSD on all our HP and haven't had issues. Our servers include: DL360 g3, g4, g4p, g5 DL380 g3, g4, g5 BL460c g1 BL480c g1 Latest edition: CPU: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz (3000.12-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd> AMD Features=0x20000800 AMD Features2=0x1 Cores per package: 4 usable memory = 34345119744 (32754 MB) avail memory = 33302040576 (31759 MB) Too bad it will run EL4 x86_64. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 07:38:11 2008 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 25FA91065672 for ; Sun, 16 Mar 2008 07:38:11 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 253CD8FC19 for ; Sun, 16 Mar 2008 07:38:11 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id D840133D83; Sun, 16 Mar 2008 00:38:06 -0700 (PDT) Date: Sun, 16 Mar 2008 00:38:06 -0700 From: Ulf Zimmermann To: Johan Str?m Message-ID: <20080316073806.GR87650@evil.alameda.net> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <67DB8948-8B91-4563-8D21-FAA88AB5AAD0@stromnet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67DB8948-8B91-4563-8D21-FAA88AB5AAD0@stromnet.se> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 07:38:11 -0000 On Thu, Mar 13, 2008 at 12:41:53AM +0100, Johan Str?m wrote: > On Mar 13, 2008, at 12:40 AM, Joe Koberg wrote: > > >Johan Str?m wrote: > >>But.. > >>http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > >> seems to tell me that in basic mode I can only access BIOS (pre- OS) > >>using the Remote Console feature, and that after POST I have to have the > >>advanced licensed option? > >> > > > >I don't do the purchasing and we get all Advanced iLO, so I will > >take your word for it. The older generations supported text console > >(i have a 360G2 that does so). We use the HP Management agents > >under Windows for all SNMP reporting so I can't comment on the > >reporting method under other OS's. > > > > I see. Can anyone else maybe shed some light here? > iLO can send SNMP alerts when hardware issues come up, such as power supply failure, memory, fan, etc. The CISS driver will also alert in syslog/console about problems with drives. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 07:44:19 2008 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 D3A15106566C for ; Sun, 16 Mar 2008 07:44:19 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id CC9CB8FC1D for ; Sun, 16 Mar 2008 07:44:19 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id BF3B333D3E; Sun, 16 Mar 2008 00:20:15 -0700 (PDT) Date: Sun, 16 Mar 2008 00:20:15 -0700 From: Ulf Zimmermann To: Johan Str?m Message-ID: <20080316072015.GP87650@evil.alameda.net> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 07:44:20 -0000 On Thu, Mar 13, 2008 at 12:24:27AM +0100, Johan Str?m wrote: > On Mar 12, 2008, at 11:37 PM, Joe Koberg wrote: > > >The iLO is a completely separate management processor with its own > >network port. It runs its own OS and has its own IP address. It runs > >an SSL webserver for access. The iLO is accessible over the network > >any time the machine is plugged into power. I am not sure about > >IPMI access to it. > > Okay, kind of what I "expected" (havent read up very much on it yet). > > > > > > >The "normal" iLO option will give you exact textual console screen > >output and keyboard control from the moment of power-on. It will > >also let you toggle power and hit the reset button. I believe it > >uses a java applet in the browser. > > > >The "advanced" iLO option, which is license-key-unlocked, also > >provides graphical remote console, and virtual media. You can upload > >a CD or floppy image and then boot the server from it. I suspect > >the compatibility issue appears here - the virtual media probably > >emulates USB mass storage, and the OS must be able to boot from it. > > I see... So for a box that is going to run fbsd in console mode, and > hopefully never need to boot from CD after install, it sounds like the > normal mode will work splendid. > > But.. > http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > seems to tell me that in basic mode I can only access BIOS (pre-OS) using > the Remote Console feature, and that after POST I have to have the > advanced licensed option? > > "iLO 2 displays this information through the remote console applet > while in the server pre-operating system > state, enabling a non-licensed iLO 2 to observe and interact with the > server during POST activities. A non- > licensed iLO 2 cannot use remote console access after the server > completes POST and begins to load the > operating system. The iLO 2 Advanced License enables access to the > remote console at all times." > > So.. Then what? I have to configure FreeBSD to use a serial console > and continue with using serial console instead? Later in the same doc: > > ? iLO 2 Standard (unlicensed:) > NOTE: The features annotated with an asterisk (*) are not supported > on all systems. > > o Virtual Power and Reset control > o Remote serial console through POST only > ... > o Serial access* > > > Am i missing something here or will I only be able to access the > console during post, unless i configure the box to use a serial > console? Hope you can shed some light here :) > > > > > > >It has full reporting of hardware state and management log details, > >and the "home page" is a big summary with any faults outlined in red. > > Yes, that was what I expected. But can i retreive the data some other > way? IPMI, SNMP or something? Would like to gather the stats to a > central management site. Further investigation in the manual seems to > indicate that no SNMP access is available, but there is some XML > "RIBCL" interface I can use (yes this is in standard mode too :)) > > Thank you! iLO also allows you to access a virtual serial line, which can be connected to via ssh. We are running about 200 HP servers (mostly Linsux unfortunatly) but we use the serial console on some specific servers where kernel modules could fence the box and if that happens nothing will be still written to the syslog (local or remote). So we use serial console and conserver to log such things. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 14:36:01 2008 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 BEAAE106564A for ; Sun, 16 Mar 2008 14:36:01 +0000 (UTC) (envelope-from andreas.killaitis@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.77]) by mx1.freebsd.org (Postfix) with ESMTP id C65418FC1A for ; Sun, 16 Mar 2008 14:36:01 +0000 (UTC) (envelope-from andreas.killaitis@mac.com) Received: from mac.com (asmtp008-s [10.150.69.71]) by smtpoutm.mac.com (Xserve/smtpout014/MantshX 4.0) with ESMTP id m2GEORJ3002376 for ; Sun, 16 Mar 2008 07:24:28 -0700 (PDT) Received: from acheron.hades.net (p4fe57eab.dip.t-dialin.net [79.229.126.171]) (authenticated bits=0) by mac.com (Xserve/asmtp008/MantshX 4.0) with ESMTP id m2GEOOV6009863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 16 Mar 2008 07:24:26 -0700 (PDT) Message-Id: <9D1EAB2A-D456-4E5B-B129-0A121B8E46B1@mac.com> From: Andreas Killaitis 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 v919.2) Date: Sun, 16 Mar 2008 15:24:23 +0100 X-Mailer: Apple Mail (2.919.2) Subject: segmentation faults on RELENG_6 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, 16 Mar 2008 14:36:01 -0000 Hi list, I have some problems with one of my FreeBSD installations. I am not shure if this the correct list, but I hope so. The scenario: I am running three virtual machines (VMware Fusion 1.1 on a Mac Pro). All of them use exactly the same hardware playground. Each of the machines is running with a different FreeBSD installation: RELENG_5, RELENG_6 and RELENG_7. There is another virtual machine with 8-CURRENT with a slightly different setup, but all of the VMs are using two virtual processors, 512 MB RAM and a 100 GB harddisk. The RELENG_5, RELENG_7 and the CURRENT machine are working like a charm, but the RELENG_6 maching is causing trouble. Sometimes some sort of processes abort with a segmentation fault: Mar 15 23:49:30 beastie6 kernel: pid 77039 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 00:12:47 beastie6 kernel: pid 35211 (conftest), uid 0: exited on signal 12 (core dumped) Mar 16 00:15:50 beastie6 kernel: pid 61400 (tr), uid 0: exited on signal 11 (core dumped) Mar 16 01:37:13 beastie6 kernel: pid 62336 (cc1), uid 0: exited on signal 11 (core dumped) Mar 16 01:51:06 beastie6 kernel: pid 41313 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 02:03:10 beastie6 kernel: pid 3826 (cc1plus), uid 0: exited on signal 11 (core dumped) Mar 16 09:40:33 beastie6 kernel: pid 6094 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:19:56 beastie6 kernel: pid 94667 (xargs), uid 0: exited on signal 11 (core dumped) Mar 16 11:20:12 beastie6 kernel: pid 97386 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:27:49 beastie6 kernel: pid 22796 (pkg_info), uid 0: exited on signal 11 (core dumped) Mar 16 11:48:09 beastie6 kernel: pid 97969 (cat), uid 0: exited on signal 11 (core dumped) Mar 16 12:05:44 beastie6 kernel: pid 16624 (bdftopcf), uid 0: exited on signal 11 (core dumped) Mar 16 13:15:04 beastie6 kernel: pid 49750 (sed), uid 0: exited on signal 11 (core dumped) All those segmentatiopn faults occurred building some ports. None of my FreeBSD boxes uses special CFLAG settings for buildworld or ports, they just use the default settings, with the exception of CPUTYPE?=pentiumpro Initially I tried CPUTYPE?=prescott, reverting it to pentium4, pentium3 and now even to pentiumpro, but even pentiumpro doesn't solve the problem. The whone world is built using those very conservative settings. My last idea is to remove even this last "tuning" parameter CPUTYPE, but I dislike this, for it would mean to run a plain 386 box. :-( Any ideas? btw: the kernel is build using the SMP flag as the only modification. The SCHED_4BSD is used. The source tree is RELENG_6 from yesterday. Regards, Andreas Killaitis From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 17:13:41 2008 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 5D409106566C for ; Sun, 16 Mar 2008 17:13:41 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33704.mail.mud.yahoo.com (web33704.mail.mud.yahoo.com [68.142.201.201]) by mx1.freebsd.org (Postfix) with SMTP id 20BA18FC13 for ; Sun, 16 Mar 2008 17:13:41 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 55549 invoked by uid 60001); 16 Mar 2008 17:13:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=Ag+EmGNxKNBLC1L3UXpLZXT2qW+dCznDm1L8Jv79pStOMqKB3/3Xgy3Ol+VWdnLPG5IdgOB5ab0xD4FMMs2c1SCO0vhLDl8XELzjwWbNb9puMmf7hC7ufJA47l81WtHRX+KbdNrffe4HBIbeXMb71/nL7gizj386rJnYCAsAfHk=; X-YMail-OSG: 2PokV54VM1lxxcfhTNHbkjusv8Oayv3FSnWwEU7Ib32WbbaI5DWS9EvhU_Oven4b.gzUiD.B9d7OCjkztDgrb.1j5ZbKr0YDC06bC27OqxuYvY0Dop8- Received: from [82.148.96.69] by web33704.mail.mud.yahoo.com via HTTP; Sun, 16 Mar 2008 10:13:40 PDT X-Mailer: YahooMailRC/902.38 YahooMailWebService/0.7.162 Date: Sun, 16 Mar 2008 10:13:40 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: FreeBSD STABLE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <462797.54831.qm@web33704.mail.mud.yahoo.com> Subject: RELENG_7 /src/UPDATING out od date? 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, 16 Mar 2008 17:13:41 -0000 Hey, http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.507;only_with_tag=RELENG_7 NOTE TO PEOPLE WHO THINK THAT FreeBSD 7.x IS SLOW: FreeBSD 7.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. Could someone please nuke this? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 18:29:15 2008 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 A0A1B1065684 for ; Sun, 16 Mar 2008 18:29:15 +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 2C6678FC3A for ; Sun, 16 Mar 2008 18:29:14 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JaxbY-0000Uz-T3 for freebsd-stable@freebsd.org; Sun, 16 Mar 2008 18:29:08 +0000 Received: from adsl-69-234-229-244.dsl.irvnca.pacbell.net ([69.234.229.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Mar 2008 18:29:08 +0000 Received: from w41ter by adsl-69-234-229-244.dsl.irvnca.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Mar 2008 18:29:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: walt Date: Sun, 16 Mar 2008 11:30:21 -0700 Lines: 78 Message-ID: References: <9D1EAB2A-D456-4E5B-B129-0A121B8E46B1@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adsl-69-234-229-244.dsl.irvnca.pacbell.net User-Agent: Thunderbird 3.0a1pre (X11/2008031604) In-Reply-To: <9D1EAB2A-D456-4E5B-B129-0A121B8E46B1@mac.com> Sender: news Subject: Re: segmentation faults on RELENG_6 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, 16 Mar 2008 18:29:15 -0000 Andreas Killaitis wrote: > Hi list, > > I have some problems with one of my FreeBSD installations. I am not > shure if this the correct list, but I hope so. > > The scenario: > > I am running three virtual machines (VMware Fusion 1.1 on a Mac Pro). > All of them use exactly the same hardware playground. Each of the > machines is running with a different FreeBSD installation: RELENG_5, > RELENG_6 and RELENG_7. There is another virtual machine with 8-CURRENT > with a slightly different setup, but all of the VMs are using two > virtual processors, 512 MB RAM and a 100 GB harddisk. The RELENG_5, > RELENG_7 and the CURRENT machine are working like a charm, but the > RELENG_6 maching is causing trouble. Sometimes some sort of processes > abort with a segmentation fault: > > Mar 15 23:49:30 beastie6 kernel: pid 77039 (sed), uid 0: exited on > signal 11 (core dumped) > Mar 16 00:12:47 beastie6 kernel: pid 35211 (conftest), uid 0: exited on > signal 12 (core dumped) > Mar 16 00:15:50 beastie6 kernel: pid 61400 (tr), uid 0: exited on signal > 11 (core dumped) > Mar 16 01:37:13 beastie6 kernel: pid 62336 (cc1), uid 0: exited on > signal 11 (core dumped) > Mar 16 01:51:06 beastie6 kernel: pid 41313 (sed), uid 0: exited on > signal 11 (core dumped) > Mar 16 02:03:10 beastie6 kernel: pid 3826 (cc1plus), uid 0: exited on > signal 11 (core dumped) > Mar 16 09:40:33 beastie6 kernel: pid 6094 (sed), uid 0: exited on signal > 11 (core dumped) > Mar 16 11:19:56 beastie6 kernel: pid 94667 (xargs), uid 0: exited on > signal 11 (core dumped) > Mar 16 11:20:12 beastie6 kernel: pid 97386 (sed), uid 0: exited on > signal 11 (core dumped) > Mar 16 11:27:49 beastie6 kernel: pid 22796 (pkg_info), uid 0: exited on > signal 11 (core dumped) > Mar 16 11:48:09 beastie6 kernel: pid 97969 (cat), uid 0: exited on > signal 11 (core dumped) > Mar 16 12:05:44 beastie6 kernel: pid 16624 (bdftopcf), uid 0: exited on > signal 11 (core dumped) > Mar 16 13:15:04 beastie6 kernel: pid 49750 (sed), uid 0: exited on > signal 11 (core dumped) > > All those segmentatiopn faults occurred building some ports. > > > None of my FreeBSD boxes uses special CFLAG settings for buildworld or > ports, they just use the default settings, with the exception of > > CPUTYPE?=pentiumpro > > Initially I tried CPUTYPE?=prescott, reverting it to pentium4, pentium3 > and now even to pentiumpro, but even pentiumpro doesn't solve the > problem. The whone world is built using those very conservative > settings. My last idea is to remove even this last "tuning" parameter > CPUTYPE, but I dislike this, for it would mean to run a plain 386 box. :-( > > > Any ideas? > > btw: the kernel is build using the SMP flag as the only modification. > The SCHED_4BSD is used. The source tree is RELENG_6 from yesterday. I'm having some problems with sh segfaulting on one machine, but the hardware is so different from yours that this idea may be irrelevant to your situation: Starting on 2006/08/27 RELENG_6 updated gcc from 3.4.4 to 3.4.6, and I have a hunch that my problem may be related to that. Unfortunately, my old machine is so slow it takes 3 days to build world/kernel -- and it's my firewall, too, so I haven't tried both compilers yet. Sounds like your machine is a wee bit faster, so maybe you could try checking out sources for RELENG_6 -D2006/08/26 and try a couple of world/kernel cycles and see if it helps? I'd be interested to see. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 20:17:35 2008 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 DBF81106564A for ; Sun, 16 Mar 2008 20:17:35 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 681288FC16 for ; Sun, 16 Mar 2008 20:17:35 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 49DF31BAC24; Sun, 16 Mar 2008 21:17:34 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m2GKHVDT035020; Sun, 16 Mar 2008 21:17:31 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1205698653; bh=0OZoGKiGHy9qGtmgb0kUQEak7MFg1uvNyLMgkVt Kfw4=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=1ZGUVmlewQt fli4YsWXIUD46YR6ULROh5Zh+OmD4nQkBH9sF0DqCOWK6iRv6AMFKzW2eMTUsJq32oE PQY6X/3A== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=Ej0Q+Qf3Y/HH6p1ZK1chj7w6jruKwcJTyk+PG0q//P/abQ/gy04hpIHIsVittGlqg NAats0LNDrTttxTF/Ib2w== Message-ID: <47DD805B.6000800@restart.be> Date: Sun, 16 Mar 2008 21:17:31 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080316) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <462797.54831.qm@web33704.mail.mud.yahoo.com> In-Reply-To: <462797.54831.qm@web33704.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Cc: FreeBSD STABLE Subject: Re: RELENG_7 /src/UPDATING out od date? 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, 16 Mar 2008 20:17:36 -0000 Abdullah Ibn Hamad Al-Marri wrote: > Hey, > > http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.507;only_with_tag=RELENG_7 > > NOTE TO PEOPLE WHO THINK THAT FreeBSD 7.x IS SLOW: > FreeBSD 7.x has many debugging features turned on, in > both the kernel and userland. These features attempt to detect > incorrect use of system primitives, and encourage loud failure > through extra sanity checking and fail stop semantics. They > also substantially impact system performance. If you want to > do performance measurement, benchmarking, and optimization, > you'll want to turn them off. This includes various WITNESS- > related kernel options, INVARIANTS, malloc debugging flags > in userland, and various verbose features in the kernel. Many > developers choose to disable these features on build machines > to maximize performance. > Could someone please nuke this? It is a problem with cvsweb - see http://www.freebsd.org/cgi/query-pr.cgi?pr=120185 Henri > > Regards, > > -Abdullah Ibn Hamad Al-Marri > Arab Portal > http://www.WeArab.Net/ > > > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > _______________________________________________ > 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 Sun Mar 16 21:16:16 2008 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 33CC2106564A for ; Sun, 16 Mar 2008 21:16:16 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: from mail.dataxnet.ro (datax28.mediasat.ro [80.96.28.28]) by mx1.freebsd.org (Postfix) with SMTP id 3D2FD8FC1E for ; Sun, 16 Mar 2008 21:16:14 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: (qmail 72233 invoked by uid 1001); 16 Mar 2008 23:16:16 +0200 Date: Sun, 16 Mar 2008 23:16:16 +0200 From: Alex Popa To: Max Laier Message-ID: <20080316211616.GA67593@dataxnet.ro> References: <20080314192359.GA4677@dataxnet.ro> <20080315203121.I42065@fledge.watson.org> <200803152217.02568.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803152217.02568.max@love2party.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet 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, 16 Mar 2008 21:16:16 -0000 This is a mixed reply to both the previous mails, bear with me please. On Sat, Mar 15, 2008 at 10:16:54PM +0100, Max Laier wrote: > On Saturday 15 March 2008, Robert Watson wrote: > > On Fri, 14 Mar 2008, Alex Popa wrote: > > > [snip] > > > The LOR messages from dmesg of 7.0-STABLE are as follows: > > > > > > lock order reversal: > > > 1st 0xffffffffb19e0680 pf task mtx (pf task mtx) @ > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd > > > 0xffffff00042ea0f0 radix node head (radix node head) @ > > > /usr/src/sys/net/route.c:147 > > I haven't seen this one before, can you obtain the trace for this, please? > You might need KDB & DDB for that - not sure. I'll do my best (see below for my questions about getting a trace). > > > lock order reversal: > > > 1st 0xffffffff80938508 PFil hook read/write mutex (PFil hook > > > read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff80938c48 > > > tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > > This one is most certainly harmless and can be ignored. It is caused by > user/group rules, but a LOR with the read instance of a rwlock will not > lead to a deadlock. I'm not using uid/gid/jail rules as far as I remember. I'll add another reply with pf.conf and the script I use to generate and reload the ipfw rules (but I'll anonymize them). > > Dear Alex, > > > > Thanks for this report, and sorry about the problem. It could well be > > that the lock order warning from WITNESS is related to the hang, and > > might reflect a recursion-related bug in the pf policy routing code. > > I'm not sure to what extent you can tolerate further downtime, but it > > would be useful to gather some more information about the hang itself > > to try and confirm the involvement of lock order. In particular, if > > it's feasible, it would be very helpful if you could boot back to the > > 7-STABLE kernel (keeping the 6.2-STABLE userspace should be fine, I > > you'll need at least a new pfctl, because the ioctl interface to /dev/pf > has changed. Switching between 6.2-RELEASE-p7 (not STABLE, because as I said 6.3 exhibited the lockups too) and 7-STABLE isn't that much of a problem. The upgrade path was "buy a new hard drive, set up everything and then adapt the old config files"... actually we bought 2 harddrives, and I set them up one with amd64 and another with i386. I think /etc and /usr/local/etc are perfectly identical on these 2 (I adapted the configs from 6.2 to 7.0, but I just copied them from amd64 to i386). So, actions needed to switch: Backup the database on 6.2 (with IP/MAC mappings and a bit more), put in the 7.0 hard drive, boot off 7.0, restore DB, let it run. Total downtime should be around 7 minutes tops. > > think), and when the hang occurs, use the console debuggger (ideally > > hooked up to serial or firewire) to run the following debugging > > commands: > > > > show pcpu > > show allpcpu > > trace > > alltrace > > show allocks > > show witness > > show lockedvnods > > show uma > > show malloc This is where things get a bit tricky, and I need advice. As I said, my observation is that the keyboard seems to stop working when the lockup occurs, that is, pressing Num Lock won't toggle the state of the LED. Thus I have some doubts that trying the good-old Control-Alt-ESC would have the desired effect (dropping me into the debugger). However, I'm not that familiar with the FreeBSD architecture, and wouldn't be surprised if the LED toggling would be in another thread and the macine will actually respond to the keyboard interrupt and drop me into ddb. Also, judging by the lack of NumLock activity (it works fine when the system's up), would serial console or firewire be functional during the lockup? Also, a bit of explanations: Why I'm asking the above: The current motherboard has a serial port (and it works, we've used it), but not a firewire port. The other motherboard we tried has firewire, but no serial. As a console workstation, I can get a few with serials, but not so easy with firewire. The null modem cable might be a problem too, depending on length. Also, since the lockup isn't easily reproducible, I'll probably need to spend some hours on location and if I'm going to do that, I'd like a degree of hope that either keyboard, serial console or firewire will work. Also, firewire will require me to switch motherboards, but that can be done together with the hard drive swapping, during the night. After a bit of studying NOTES, I was wondering if a combination of serial console (or just plain console) with "options WITNESS_KDB" would help get a "good enough" trace. The upside of this is that both LORs usually occur early (not much later than the login prompt, usually earlier) as opposed to after 12...18 hours, and I can either force a panic after each and get 2 core dumps, or run the debug commands suggested (either as debug LOR1 / continue / debug LOR2, or debug LOR1 / reboot / "continue" LOR1 / debug LOR2 - whichever is more appropriate). For the moment I have both hard drives (7.0-STABLE/amd64 and 7.0-RELEASE/i386) and the new motherboard (no serial, but with firewire) as a working computer under my desk. I can prepare for the night-time switch and debug by compiling kernel and/or world and doing some preliminary testing here. If I really need to test null modem console, I can put the hdd in my own desktop and test with another machine. > > A shot-in-the-dark guess is that something about pf's interactions with > > the protocol stack is involved here, but unfortunately I suspect we'll > > need some more information to track it down. > > > > Also, could you confirm if you're using any credential-related firewall > > rules with either ipfw or pf? These would be uid/gid/jail matching > > rules. As I said above, I don't use any uid/gid/jail rules. Mail with pf.conf and ipfw config incoming shortly after this one. > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > [snip] > > That's quite a complex setup. It would really be interesting to get the > trace for the first LOR in order to figure out which code path we are > looking at. I have a feeling that it might be the dummynet entry point, > but w/o the trace this is only speculation. Working on it. > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News I'd like suggestions / comments about the kernel config I'm thinking about for debugging purposes: - take my KERNEL (GENERIC + IPFW - IPv6 and SCTP and wireless), and add: options WITNESS options WITNESS_KDB # only if debug-on-first-warn is wanted options WITNESS_SKIPSPIN options KDB #options KDB_TRACE # not needed since I'll trace anyway? options DDB #options BREAK_TO_DEBUGGER # would that work for my kind of lockup? options MSGBUF_SIZE=409600 Ideally I would like to hear that the manual tracing and debugging with a keyboard console would provide enough info. I'll increase the kernel buffer size to 400k as above, so I don't lose info when I continue and dmesg > log.txt. Just as easily, I can try forcing a panic at the LORs and keeping the kernel dumps (with optional debugging in ddb like above). The advantage is that this might andswer supplementary questions after the deed is done. Both the above options should be possible this week. The serial console part may or may not happen this week, and I'm quite positive it will take another week before I find the time to spend 16+ hours on location, waiting for a lockup (which might happen at a busy time and therefore I'll have very little time to do all the debugging). Tips / suggestions are most welcome! Thanks for the help! Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 21:45:26 2008 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 BC664106566C for ; Sun, 16 Mar 2008 21:45:26 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: from mail.dataxnet.ro (datax28.mediasat.ro [80.96.28.28]) by mx1.freebsd.org (Postfix) with SMTP id 02F4B8FC15 for ; Sun, 16 Mar 2008 21:45:24 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: (qmail 73426 invoked by uid 1001); 16 Mar 2008 23:45:27 +0200 Date: Sun, 16 Mar 2008 23:45:27 +0200 From: Alex Popa To: freebsd-stable@FreeBSD.org Message-ID: <20080316214527.GA72271@dataxnet.ro> References: <20080314192359.GA4677@dataxnet.ro> <20080315123710.GA6773@dataxnet.ro> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20080315123710.GA6773@dataxnet.ro> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (extra extra details - config files) 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, 16 Mar 2008 21:45:26 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached are pf.conf and ipfw.txt. The former is loaded by the standard means, and the latter is loaded via ipfw -q /path/to/ipfw.txt Some comments: I've anonymized the files. Address in the 10.0.0.0/8 range stand for "internal" IP addresses, meaning one /27 and three /24 networks, and address in the 192.168.0.0/16 range stand for addresses on the directly connected "external" networks, meaning the 2 fibers to the ISP. Also I've junked all but the last byte of MAC addresses in ipfw. I know the ipfw setup looks scary, but worst case a layer2 packet (I should say frame) gets checked against 38 rules (39 if it's dropped). I could probably optimize a few more rules out of this, but I'm not sure it's worth the effort. For layer3 I haven't counted, but I doubt it's more than 10 rules (more likely 6-7). Tables "metro" and "special" in pf are contolled by OpenBGPD. They are synced to ipfw tables 1 and 2 respectively, by cron jobs that run every 3 minutes and only make the necessary changes. ipfw rules below the "DO NOT EDIT" line are automatically generated from a database of IP/MAC mappings. This can change asynchronously and can cause the script to be regenerated and run. The classification is supposed to speed things up a little, by not comparing a MAC address against all hosts in its subnet, but only against sqrt(hosts) other IPs and another sqrt(hosts) IP/MAC pairs. [and it's not exactly sqrt, but about half of the bits in the host part of the IP address] Have fun Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw.txt" set move 0 to 1 set disable 0 # scary stuff, allow arp add 10 allow mac-type 0x0806 # filter MAC on input add 10 skipto 100 in recv em0 layer2 add 11 allow out xmit em0 layer2 add 12 allow in layer2 add 13 allow out layer2 # em0 - internal add 20 skipto 22000 in recv em0 add 25 allow out xmit em0 # em1 - external 1 - shape on 20000 (in) / 20500 (out) add 30 skipto 20000 in recv em1 add 35 skipto 20500 out xmit em1 # bge0 - extern 2 - shape on 21000 (in) / 21500 (out) add 40 skipto 21000 in recv bge0 add 45 skipto 21500 out xmit bge0 add 90 allow ip from any to any via lo0 add 95 allow ip from any to any -f zero # # TABLES # # 1 - metro # 2 - special # 10 - internal (all) # 11 - internal - routing external 1 (em1) # 12 - internal - routing external 2 (bge0) # 100 bandwidth A # 101 bandwidth B # 120, 121, 122 : this server: All IPs, IP bw A, IP bw B # NOTE: tables 1 and 2 are synchronized to pf tables named # "metro" and "special" by a script which runs every 3 minutes table 10 flush table 10 add 10.0.10.0/27 table 10 add 10.0.20.0/24 table 10 add 10.0.30.0/24 table 10 add 10.0.40.0/24 table 10 add 192.168.11.11 table 10 add 192.168.22.22 table 11 flush table 11 add 10.0.20.0/24 table 11 add 10.0.40.0/24 table 11 add 192.168.11.11 table 11 add 192.168.22.22 table 12 flush table 12 add 10.0.10.0/27 table 12 add 10.0.30.0/24 table 100 flush table 100 add 10.0.20.0/24 table 100 add 10.0.30.0/24 table 100 add 10.0.40.0/24 table 100 add 192.168.11.11 table 101 flush table 101 add 10.0.10.0/27 table 101 add 192.168.22.22 table 120 flush table 120 add 10.0.10.1 table 120 add 10.0.20.1 table 120 add 10.0.30.1 table 120 add 192.168.33.33 table 120 add 192.168.11.11 table 120 add 192.168.22.22 table 121 flush table 121 add 10.0.20.1 table 121 add 10.0.30.1 table 121 add 10.0.40.1 table 121 add 192.168.11.11 table 122 flush table 122 add 10.0.10.1 table 122 add 192.168.33.33 table 122 add 192.168.22.22 # # PIPES and QUEUES # -f pipe flush # bw A - in 1/out 2 pipe 1 config bw 4500kbits/s queue 1 config pipe 1 weight 10 mask dst-ip 0xffffffff pipe 2 config bw 200kbits/s mask src-ip 0xffffffff # bw B - in 3/out 4 pipe 3 config bw 1000kbits/s queue 3 config pipe 3 weight 10 mask dst-ip 0xffffffff pipe 4 config bw 1000kbits/s queue 4 config pipe 4 weight 10 mask src-ip 0xffffffff # external interface 1 (em1) - 11 in/12 out pipe 11 config bw 95Mbits/s queue 100 queue 11 config pipe 11 weight 10 mask dst-ip 0xffffffff queue 100 pipe 12 config bw 95Mbits/s queue 100 queue 12 config pipe 12 weight 10 mask src-ip 0xffffffff queue 100 # external interface 2 (bge0) - 21 in/22 out pipe 21 config bw 95Mbits/s queue 100 queue 21 config pipe 21 weight 10 mask dst-ip 0xffffffff queue 100 pipe 22 config bw 95Mbits/s queue 100 queue 22 config pipe 22 weight 10 mask src-ip 0xffffffff queue 100 ### # # Shaping - check order: Metro / Special / A / B (3 in, 3 out) # ### # em1 - ext 1 shaping - 20000/20500 add 20000 queue 11 ip from table(1) to any add 20005 queue 11 ip from table(2) to any add 20010 queue 1 ip from any to table(100) add 20010 queue 3 ip from any to table(101) add 20499 allow ip from any to any # only shape locally-generated traffic here, # the rest is matched on entry [em0] add 20500 queue 12 ip from table(120) to table(1) add 20505 queue 12 ip from table(120) to table(2) add 20510 pipe 2 ip from table(121) to any add 20515 queue 4 ip from table(122) to any add 20999 allow ip from any to any # bge0 - ext 2 shaping - 21000/21500 add 21000 queue 21 ip from table(1) to any add 21005 queue 21 ip from table(2) to any add 21010 queue 1 ip from any to table(100) add 21015 queue 3 ip from any to table(101) add 21499 allow ip from any to any # same as external 1, only locally generated add 21500 queue 22 ip from table(120) to table(1) add 21505 queue 22 ip from table(120) to table(2) add 21510 pipe 2 ip from table(121) to any add 21515 queue 4 ip from table(122) to any add 21999 allow ip from any to any # em0 - internal # from internal to internal - no limit - yay for gigabit add 22000 allow ip from table(10) to table(10) add 22005 allow ip from table(10) to 127.0.0.1 # from internal to "external" but it goes to the proxy on this machine - don't double shape add 22050 allow tcp from table(10) to any 80 add 22055 allow tcp from table(10) to 127.0.0.1 8000 ## special - from any source packets will be routed out external 1 so count in that queue add 22100 queue 12 ip from any to table(2) ## metro - some sources are counted against external 1, others against external 2 add 22105 queue 12 ip from table(11) to table(1) add 22110 queue 22 ip from table(12) to table(1) # non-metro, go to slow pipes add 22115 pipe 2 ip from table(100) to any add 22120 queue 4 ip from table(101) to any # this rule should always have its counters at 0 or something's missing above add 22499 allow ip from any to any # DO NOT EDIT BELOW THIS LINE! - AUTO GENERATED add 100 skipto 1000 ip from 10.0.10.0/27 to any add 101 skipto 1100 ip from 10.0.20.0/24 to any add 102 skipto 1200 ip from 10.0.30.0/24 to any add 103 skipto 1300 ip from 10.0.40.0/24 to any add 1000 skipto 2000 ip from 10.0.10.0/29 to any add 1001 skipto 2100 ip from 10.0.10.8/29 to any add 1002 skipto 2200 ip from 10.0.10.16/29 to any add 1003 skipto 2300 ip from 10.0.10.24/29 to any add 1100 skipto 2400 ip from 10.0.20.0/28 to any add 1101 skipto 2500 ip from 10.0.20.16/28 to any add 1102 skipto 2600 ip from 10.0.20.32/28 to any add 1103 skipto 2700 ip from 10.0.20.48/28 to any add 1104 skipto 2800 ip from 10.0.20.64/28 to any add 1105 skipto 2900 ip from 10.0.20.80/28 to any add 1106 skipto 3000 ip from 10.0.20.96/28 to any add 1107 skipto 3100 ip from 10.0.20.112/28 to any add 1108 skipto 3200 ip from 10.0.20.128/28 to any add 1109 skipto 3300 ip from 10.0.20.144/28 to any add 1110 skipto 3400 ip from 10.0.20.160/28 to any add 1111 skipto 3500 ip from 10.0.20.176/28 to any add 1112 skipto 3600 ip from 10.0.20.192/28 to any add 1113 skipto 3700 ip from 10.0.20.208/28 to any add 1114 skipto 3800 ip from 10.0.20.224/28 to any add 1115 skipto 3900 ip from 10.0.20.240/28 to any add 1200 skipto 4000 ip from 10.0.30.0/28 to any add 1201 skipto 4100 ip from 10.0.30.16/28 to any add 1202 skipto 4200 ip from 10.0.30.32/28 to any add 1203 skipto 4300 ip from 10.0.30.48/28 to any add 1204 skipto 4400 ip from 10.0.30.64/28 to any add 1205 skipto 4500 ip from 10.0.30.80/28 to any add 1206 skipto 4600 ip from 10.0.30.96/28 to any add 1207 skipto 4700 ip from 10.0.30.112/28 to any add 1208 skipto 4800 ip from 10.0.30.128/28 to any add 1209 skipto 4900 ip from 10.0.30.144/28 to any add 1210 skipto 5000 ip from 10.0.30.160/28 to any add 1211 skipto 5100 ip from 10.0.30.176/28 to any add 1212 skipto 5200 ip from 10.0.30.192/28 to any add 1213 skipto 5300 ip from 10.0.30.208/28 to any add 1214 skipto 5400 ip from 10.0.30.224/28 to any add 1215 skipto 5500 ip from 10.0.30.240/28 to any add 1300 skipto 5600 ip from 10.0.40.0/28 to any add 1301 skipto 5700 ip from 10.0.40.16/28 to any add 1302 skipto 5800 ip from 10.0.40.32/28 to any add 1303 skipto 5900 ip from 10.0.40.48/28 to any add 1304 skipto 6000 ip from 10.0.40.64/28 to any add 1305 skipto 6100 ip from 10.0.40.80/28 to any add 1306 skipto 6200 ip from 10.0.40.96/28 to any add 1307 skipto 6300 ip from 10.0.40.112/28 to any add 1308 skipto 6400 ip from 10.0.40.128/28 to any add 1309 skipto 6500 ip from 10.0.40.144/28 to any add 1310 skipto 6600 ip from 10.0.40.160/28 to any add 1311 skipto 6700 ip from 10.0.40.176/28 to any add 1312 skipto 6800 ip from 10.0.40.192/28 to any add 1313 skipto 6900 ip from 10.0.40.208/28 to any add 1314 skipto 7000 ip from 10.0.40.224/28 to any add 1315 skipto 7100 ip from 10.0.40.240/28 to any add 104 deny ip from any to any add 1099 deny ip from any to any add 1199 deny ip from any to any add 1299 deny ip from any to any add 1399 deny ip from any to any add 2099 deny ip from any to any add 2199 deny ip from any to any add 2299 deny ip from any to any add 2399 deny ip from any to any add 2499 deny ip from any to any add 2599 deny ip from any to any add 2699 deny ip from any to any add 2799 deny ip from any to any add 2899 deny ip from any to any add 2999 deny ip from any to any add 3099 deny ip from any to any add 3199 deny ip from any to any add 3299 deny ip from any to any add 3399 deny ip from any to any add 3499 deny ip from any to any add 3599 deny ip from any to any add 3699 deny ip from any to any add 3799 deny ip from any to any add 3899 deny ip from any to any add 3999 deny ip from any to any add 4099 deny ip from any to any add 4199 deny ip from any to any add 4299 deny ip from any to any add 4399 deny ip from any to any add 4499 deny ip from any to any add 4599 deny ip from any to any add 4699 deny ip from any to any add 4799 deny ip from any to any add 4899 deny ip from any to any add 4999 deny ip from any to any add 5099 deny ip from any to any add 5199 deny ip from any to any add 5299 deny ip from any to any add 5399 deny ip from any to any add 5499 deny ip from any to any add 5599 deny ip from any to any add 5699 deny ip from any to any add 5799 deny ip from any to any add 5899 deny ip from any to any add 5999 deny ip from any to any add 6099 deny ip from any to any add 6199 deny ip from any to any add 6299 deny ip from any to any add 6399 deny ip from any to any add 6499 deny ip from any to any add 6599 deny ip from any to any add 6699 deny ip from any to any add 6799 deny ip from any to any add 6899 deny ip from any to any add 6999 deny ip from any to any add 7099 deny ip from any to any add 7199 deny ip from any to any # This comment doesn't exist in the original file. # A few hundred lines below have been deleted, but you should get the idea. # Note rule numbers aren't in order, they depend on how the IP # addresses are pulled out of the DB add 2004 pass ip from 10.0.10.4 to any mac any 00:de:ad:be:ef:01 add 2201 pass ip from 10.0.10.17 to any mac any 00:de:ad:be:ef:ff add 2206 pass ip from 10.0.10.22 to any mac any 00:de:ad:be:ef:cd add 2412 pass ip from 10.0.20.12 to any mac any 00:de:ad:be:ef:c3 add 2415 pass ip from 10.0.20.15 to any mac any 00:de:ad:be:ef:25 add 2515 pass ip from 10.0.20.31 to any mac any 00:de:ad:be:ef:7d add 2604 pass ip from 10.0.20.36 to any mac any 00:de:ad:be:ef:97 add 2702 pass ip from 10.0.20.50 to any mac any 00:de:ad:be:ef:15 add 2705 pass ip from 10.0.20.53 to any mac any 00:de:ad:be:ef:0d add 2802 pass ip from 10.0.20.66 to any mac any 00:de:ad:be:ef:a6 add 2905 pass ip from 10.0.20.85 to any mac any 00:de:ad:be:ef:de add 3012 pass ip from 10.0.20.108 to any mac any 00:de:ad:be:ef:c7 add 3015 pass ip from 10.0.20.111 to any mac any 00:de:ad:be:ef:a3 add 3201 pass ip from 10.0.20.129 to any mac any 00:de:ad:be:ef:d8 add 3207 pass ip from 10.0.20.135 to any mac any 00:de:ad:be:ef:5b add 3304 pass ip from 10.0.20.148 to any mac any 00:de:ad:be:ef:bb add 3307 pass ip from 10.0.20.151 to any mac any 00:de:ad:be:ef:f5 add 3407 pass ip from 10.0.20.167 to any mac any 00:de:ad:be:ef:5c add 3410 pass ip from 10.0.20.170 to any mac any 00:de:ad:be:ef:0b add 3513 pass ip from 10.0.20.189 to any mac any 00:de:ad:be:ef:cd add 3600 pass ip from 10.0.20.192 to any mac any 00:de:ad:be:ef:85 add 3702 pass ip from 10.0.20.210 to any mac any 00:de:ad:be:ef:21 add 3706 pass ip from 10.0.20.214 to any mac any 00:de:ad:be:ef:4c add 3806 pass ip from 10.0.20.230 to any mac any 00:de:ad:be:ef:08 add 3809 pass ip from 10.0.20.233 to any mac any 00:de:ad:be:ef:fc add 4002 pass ip from 10.0.30.2 to any mac any 00:de:ad:be:ef:1e add 4005 pass ip from 10.0.30.5 to any mac any 00:de:ad:be:ef:86 add 4102 pass ip from 10.0.30.18 to any mac any 00:de:ad:be:ef:55 add 4206 pass ip from 10.0.30.38 to any mac any 00:de:ad:be:ef:fe add 4303 pass ip from 10.0.30.51 to any mac any 00:de:ad:be:ef:e0 add 4306 pass ip from 10.0.30.54 to any mac any 00:de:ad:be:ef:7a add 4405 pass ip from 10.0.30.69 to any mac any 00:de:ad:be:ef:e5 add 4410 pass ip from 10.0.30.74 to any mac any 00:de:ad:be:ef:bd add 4510 pass ip from 10.0.30.90 to any mac any 00:de:ad:be:ef:6d add 4700 pass ip from 10.0.30.112 to any mac any 00:de:ad:be:ef:8d add 4802 pass ip from 10.0.30.130 to any mac any 00:de:ad:be:ef:cd add 4912 pass ip from 10.0.30.156 to any mac any 00:de:ad:be:ef:48 add 5010 pass ip from 10.0.30.170 to any mac any 00:de:ad:be:ef:52 add 5014 pass ip from 10.0.30.174 to any mac any 00:de:ad:be:ef:36 add 5113 pass ip from 10.0.30.189 to any mac any 00:de:ad:be:ef:56 add 5407 pass ip from 10.0.30.231 to any mac any 00:de:ad:be:ef:b4 add 5508 pass ip from 10.0.30.248 to any mac any 00:de:ad:be:ef:5d add 5511 pass ip from 10.0.30.251 to any mac any 00:de:ad:be:ef:68 add 5714 pass ip from 10.0.40.30 to any mac any 00:de:ad:be:ef:81 add 5801 pass ip from 10.0.40.33 to any mac any 00:de:ad:be:ef:15 add 7015 pass ip from 10.0.40.239 to any mac any 00:de:ad:be:ef:3e add 7103 pass ip from 10.0.40.243 to any mac any 00:de:ad:be:ef:b1 add 2508 pass ip from 10.0.20.24 to any mac any 00:de:ad:be:ef:95 add 2603 pass ip from 10.0.20.35 to any mac any 00:de:ad:be:ef:d0 add 3607 pass ip from 10.0.20.199 to any mac any 00:de:ad:be:ef:20 add 3705 pass ip from 10.0.20.213 to any mac any 00:de:ad:be:ef:6e add 5006 pass ip from 10.0.30.166 to any mac any 00:de:ad:be:ef:f7 add 5208 pass ip from 10.0.30.200 to any mac any 00:de:ad:be:ef:15 add 7008 pass ip from 10.0.40.232 to any mac any 00:de:ad:be:ef:7d add 7102 pass ip from 10.0.40.242 to any mac any 00:de:ad:be:ef:bb add 7114 pass ip from 10.0.40.254 to any mac any 00:de:ad:be:ef:30 set enable 0 delete set 1 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pf.txt" ext_if0="em1" ext_if1="bge0" ext_ifaces="{em1, bge0}" int_if="em0" internal_net_1="10.0.10.0/27" internal_ip0="10.0.10.1" internal_net_2="10.0.20.0/24" internal_ip1="10.0.20.1" internal_net_3="10.0.30.0/24" internal_ip2="10.0.30.1" internal_net_4="10.0.40.0/24" internal_ip3="10.0.40.1" external_ip0="192.168.11.11" external_ip1="192.168.22.22" external1_ip="192.168.33.33" external_router="192.168.11.1" external_router1="192.168.22.1" localhost="127.0.0.1" set timeout { tcp.closing 600, tcp.finwait 30, tcp.closed 60 } set limit { states 50000, frags 15000 } set skip on lo0 table { 10.0.10.1, 10.0.20.1, 10.0.30.1, 10.0.40.1, 192.168.11.11, 192.168.22.22, 192.168.33.33} persist table { 10.0.10.1, 10.0.30.1, 10.0.20.1, 10.0.40.1 } table { 10.0.10.0/27, 10.0.30.0/24, 10.0.20.0/24, 10.0.40.0/24 } table persist table persist table { 10.0.30.123 } persist # Prevent UCE issues - no outgoing SMTP from these table persist { 10.0.30.0/24, 10.0.40.0/24, 10.0.20.14, 10.0.20.20, 10.0.20.200 } table persist {10.0.30.30, 10.0.30.130, 10.0.40.40, 10.0.40.140} table { 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.0/30 } # users with malware, force them to clean up - redirect to "call us" page table persist file "/etc/ip-force-clean" # force-clean rdr on $int_if proto tcp from to any port 80 -> $localhost port 81 rdr on $int_if proto tcp from to port 8000 -> $localhost port 81 no rdr on $int_if proto tcp from any to port 80 no rdr on $int_if proto tcp from to any port 80 no rdr on $int_if proto tcp from any to port 80 no rdr on $int_if proto tcp from any to port 80 rdr on $int_if proto tcp from any to any port 80 -> $localhost port 8000 ## oops, this is really old here, keeping it just for the sake of full reporting anchor "temptest" # malware gets no traffic from the outside block in quick on $ext_if0 from any to block in quick on $ext_if1 from any to # this server block in log from any to pass out from to any keep state # public services pass in log proto icmp from any to pass in log proto tcp from any to port 53 keep state pass in proto udp from any to port 53 keep state pass in log proto tcp from any to port 80 keep state pass in log proto tcp from any to port 443 keep state # ssh - this server and 10.0.10.12 are restricted pass in log proto tcp from to port 22 keep state label "ssh" block in log proto tcp from any to 10.0.10.12 port 22 pass in log proto tcp from to 10.0.10.12 port 22 keep state label "ssh" pass in log proto tcp from to 10.0.10.12 port 22 keep state label "ssh" # allow access to the proxy pass in proto tcp from to port 8000 keep state pass in proto tcp from to $localhost port 8000 keep state # port 25 policy - a bit hairy pass in log proto tcp from any to any port = 25 keep state pass in quick log proto tcp from to any port = 25 keep state pass in quick log proto tcp from 10.0.10.28 to 10.0.10.1 port = 25 keep state #block side block in quick log proto tcp from to any port = 25 block in quick log proto tcp from to any port = 25 # Policy routing # first rule commented for the last 3 months # pass out on $ext_if0 route-to ($ext_if1 $external_router1) from $internal_net_1 to ! keep state pass out on $ext_if0 fastroute from $internal_net_1 to keep state pass in on $int_if fastroute from $internal_net_1 to $localhost keep state pass out on $ext_if0 route-to ($ext_if1 $external_router1) from $internal_net_2 to ! keep state pass out on $ext_if0 fastroute from $internal_net_2 to keep state pass in on $int_if fastroute from $internal_net_2 to $localhost keep state pass in on $int_if fastroute from $internal_net_3 to $localhost keep state pass in on $int_if fastroute from $internal_net_4 to $localhost keep state # Explanation for the rules above: # # Net 1 used to be routed via external1, but it's no longer the case (only half of its policy routing is commented out). # # Most net 2 traffic goes out via external1 interface, except localhost (transparent proxy causes localhost traffic) and # traffic to "special" which should use the normal route - hence the "fastroute". # force-clean -> warning, plus ping and DNS block in on $int_if from to any pass in on $int_if proto tcp from to $localhost port 81 keep state pass in on $int_if proto icmp from to pass in on $int_if proto udp from to port 53 pass in on $int_if proto tcp from to port 53 # just a good idea block in proto udp from any to any port 137:139 block in proto tcp from any to any port 137:139 block in proto tcp from any to any port 135 block in proto tcp from any to any port 445 block in proto udp from any to any port 1434 block in proto udp from any to any port 1433 --4Ckj6UjgE2iN1+kY-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 22:37:05 2008 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 DB94A106566B; Sun, 16 Mar 2008 22:37:05 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from queueout04-winn.ispmail.ntl.com (queueout04-winn.ispmail.ntl.com [81.103.221.58]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7168FC16; Sun, 16 Mar 2008 22:37:04 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20080316221919.YKAE27871.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Sun, 16 Mar 2008 22:19:19 +0000 Received: from cpc2-cove3-0-0-cust311.sol2.cable.ntl.com ([86.20.33.56]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20080316221648.PTH29112.aamtaout04-winn.ispmail.ntl.com@cpc2-cove3-0-0-cust311.sol2.cable.ntl.com>; Sun, 16 Mar 2008 22:16:48 +0000 X-Virus-Scanned: amavisd-new at cpc1-cove3-0-0-cust839.sol2.cable.ntl.com Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by cpc2-cove3-0-0-cust311.sol2.cable.ntl.com (8.14.2/8.14.2) with ESMTP id m2GMGKRO002940; Sun, 16 Mar 2008 22:16:20 GMT (envelope-from ianjhart@ntlworld.com) From: ian j hart To: freebsd-stable@freebsd.org Date: Sun, 16 Mar 2008 22:16:20 +0000 User-Agent: KMail/1.9.7 References: <20080314192359.GA4677@dataxnet.ro> <200803152217.02568.max@love2party.net> <20080316211616.GA67593@dataxnet.ro> In-Reply-To: <20080316211616.GA67593@dataxnet.ro> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803162216.20041.ianjhart@ntlworld.com> Cc: Max Laier , Robert Watson , Alex Popa Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet 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, 16 Mar 2008 22:37:06 -0000 On Sunday 16 March 2008 21:16:16 Alex Popa wrote: > This is a mixed reply to both the previous mails, bear with me please. > > On Sat, Mar 15, 2008 at 10:16:54PM +0100, Max Laier wrote: > > On Saturday 15 March 2008, Robert Watson wrote: > > > On Fri, 14 Mar 2008, Alex Popa wrote: > > > > [snip] > > > > The LOR messages from dmesg of 7.0-STABLE are as follows: > > > > > > > > lock order reversal: > > > > 1st 0xffffffffb19e0680 pf task mtx (pf task mtx) @ > > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd > > > > 0xffffff00042ea0f0 radix node head (radix node head) @ > > > > /usr/src/sys/net/route.c:147 > > > > I haven't seen this one before, can you obtain the trace for this, > > please? You might need KDB & DDB for that - not sure. > > I'll do my best (see below for my questions about getting a trace). > > > > > lock order reversal: > > > > 1st 0xffffffff80938508 PFil hook read/write mutex (PFil hook > > > > read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff80938c48 > > > > tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > > > > This one is most certainly harmless and can be ignored. It is caused by > > user/group rules, but a LOR with the read instance of a rwlock will not > > lead to a deadlock. > > I'm not using uid/gid/jail rules as far as I remember. I'll add another > reply with pf.conf and the script I use to generate and reload the ipfw > rules (but I'll anonymize them). > > > > Dear Alex, > > > > > > Thanks for this report, and sorry about the problem. It could well be > > > that the lock order warning from WITNESS is related to the hang, and > > > might reflect a recursion-related bug in the pf policy routing code. > > > I'm not sure to what extent you can tolerate further downtime, but it > > > would be useful to gather some more information about the hang itself > > > to try and confirm the involvement of lock order. In particular, if > > > it's feasible, it would be very helpful if you could boot back to the > > > 7-STABLE kernel (keeping the 6.2-STABLE userspace should be fine, I > > > > you'll need at least a new pfctl, because the ioctl interface to /dev/pf > > has changed. > > Switching between 6.2-RELEASE-p7 (not STABLE, because as I said 6.3 > exhibited the lockups too) and 7-STABLE isn't that much of a problem. > The upgrade path was "buy a new hard drive, set up everything and then > adapt the old config files"... actually we bought 2 harddrives, and I > set them up one with amd64 and another with i386. I think /etc and > /usr/local/etc are perfectly identical on these 2 (I adapted the configs > from 6.2 to 7.0, but I just copied them from amd64 to i386). > > So, actions needed to switch: Backup the database on 6.2 (with IP/MAC > mappings and a bit more), put in the 7.0 hard drive, boot off 7.0, > restore DB, let it run. Total downtime should be around 7 minutes tops. > > > > think), and when the hang occurs, use the console debuggger (ideally > > > hooked up to serial or firewire) to run the following debugging > > > commands: > > > > > > show pcpu > > > show allpcpu > > > trace > > > alltrace > > > show allocks > > > show witness > > > show lockedvnods > > > show uma > > > show malloc > > This is where things get a bit tricky, and I need advice. > > As I said, my observation is that the keyboard seems to stop working > when the lockup occurs, that is, pressing Num Lock won't toggle the > state of the LED. Thus I have some doubts that trying the good-old > Control-Alt-ESC would have the desired effect (dropping me into the > debugger). However, I'm not that familiar with the FreeBSD > architecture, and wouldn't be surprised if the LED toggling would be in > another thread and the macine will actually respond to the keyboard > interrupt and drop me into ddb. Also, judging by the lack of NumLock > activity (it works fine when the system's up), would serial console or > firewire be functional during the lockup? Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux). I'd double check they work before you rely on this as a diagnostic tool. > > Also, a bit of explanations: > > Why I'm asking the above: The current motherboard has a serial port > (and it works, we've used it), but not a firewire port. The other > motherboard we tried has firewire, but no serial. As a console > workstation, I can get a few with serials, but not so easy with > firewire. The null modem cable might be a problem too, depending on > length. > > Also, since the lockup isn't easily reproducible, I'll probably need to > spend some hours on location and if I'm going to do that, I'd like a > degree of hope that either keyboard, serial console or firewire will > work. Also, firewire will require me to switch motherboards, but that > can be done together with the hard drive swapping, during the night. > > After a bit of studying NOTES, I was wondering if a combination of > serial console (or just plain console) with "options WITNESS_KDB" would > help get a "good enough" trace. The upside of this is that both LORs > usually occur early (not much later than the login prompt, usually > earlier) as opposed to after 12...18 hours, and I can either force a > panic after each and get 2 core dumps, or run the debug commands > suggested (either as debug LOR1 / continue / debug LOR2, or debug LOR1 / > reboot / "continue" LOR1 / debug LOR2 - whichever is more appropriate). > > For the moment I have both hard drives (7.0-STABLE/amd64 and > 7.0-RELEASE/i386) and the new motherboard (no serial, but with firewire) > as a working computer under my desk. I can prepare for the night-time > switch and debug by compiling kernel and/or world and doing some > preliminary testing here. If I really need to test null modem console, > I can put the hdd in my own desktop and test with another machine. > > > > A shot-in-the-dark guess is that something about pf's interactions with > > > the protocol stack is involved here, but unfortunately I suspect we'll > > > need some more information to track it down. > > > > > > Also, could you confirm if you're using any credential-related firewall > > > rules with either ipfw or pf? These would be uid/gid/jail matching > > > rules. > > As I said above, I don't use any uid/gid/jail rules. Mail with pf.conf > and ipfw config incoming shortly after this one. > > > > Robert N M Watson > > > Computer Laboratory > > > University of Cambridge > > [snip] > > > That's quite a complex setup. It would really be interesting to get the > > trace for the first LOR in order to figure out which code path we are > > looking at. I have a feeling that it might be the dummynet entry point, > > but w/o the trace this is only speculation. > > Working on it. > > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > I'd like suggestions / comments about the kernel config I'm thinking > about for debugging purposes: > > - take my KERNEL (GENERIC + IPFW - IPv6 and SCTP and wireless), and add: > > options WITNESS > options WITNESS_KDB # only if debug-on-first-warn is wanted > options WITNESS_SKIPSPIN > options KDB > #options KDB_TRACE # not needed since I'll trace anyway? > options DDB > #options BREAK_TO_DEBUGGER # would that work for my kind of lockup? > options MSGBUF_SIZE=409600 > > > Ideally I would like to hear that the manual tracing and debugging with > a keyboard console would provide enough info. I'll increase the kernel > buffer size to 400k as above, so I don't lose info when I continue and > dmesg > log.txt. > > Just as easily, I can try forcing a panic at the LORs and keeping the > kernel dumps (with optional debugging in ddb like above). The advantage > is that this might andswer supplementary questions after the deed is > done. > > Both the above options should be possible this week. > > The serial console part may or may not happen this week, and I'm quite > positive it will take another week before I find the time to spend 16+ > hours on location, waiting for a lockup (which might happen at a busy > time and therefore I'll have very little time to do all the debugging). > > Tips / suggestions are most welcome! > > Thanks for the help! > Alex -- ian j hart From owner-freebsd-stable@FreeBSD.ORG Sun Mar 16 23:10:30 2008 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 460CF1065725 for ; Sun, 16 Mar 2008 23:10:29 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: from mail.dataxnet.ro (datax28.mediasat.ro [80.96.28.28]) by mx1.freebsd.org (Postfix) with SMTP id 274188FC15 for ; Sun, 16 Mar 2008 23:10:27 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: (qmail 76297 invoked by uid 1001); 17 Mar 2008 01:10:29 +0200 Date: Mon, 17 Mar 2008 01:10:29 +0200 From: Alex Popa To: ian j hart Message-ID: <20080316231029.GA76264@dataxnet.ro> References: <20080314192359.GA4677@dataxnet.ro> <200803152217.02568.max@love2party.net> <20080316211616.GA67593@dataxnet.ro> <200803162216.20041.ianjhart@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803162216.20041.ianjhart@ntlworld.com> User-Agent: Mutt/1.4.2.2i Cc: Robert Watson , Max Laier , freebsd-stable@freebsd.org Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet 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, 16 Mar 2008 23:10:30 -0000 On Sun, Mar 16, 2008 at 10:16:20PM +0000, ian j hart wrote: > Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux). > I'd double check they work before you rely on this as a diagnostic tool. > > -- > ian j hart Well, that was the most basic test. I should have mentioned that, during the lockup: (a) Before I removed the "saver" line in rc.conf, hitting a key wouldn't turn the screensaver off. I removed it in case the kernel was writing *something* to the console, so I could get a glimpse. (b) Console switching no longer worked. Hope this helps Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 05:46:48 2008 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 C089F106564A for ; Mon, 17 Mar 2008 05:46:48 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (209-193-47-81-cdsl-rb1.fai.acsalaska.net [209.193.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id 723FD8FC16 for ; Mon, 17 Mar 2008 05:46:43 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (localhost.65north.com [127.0.0.1]) by jago.65north.com (8.13.3/8.13.3) with ESMTP id m2H5Tsxj002421 for ; Sun, 16 Mar 2008 21:29:54 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Received: from localhost (pstern@localhost) by jago.65north.com (8.13.3/8.13.3/Submit) with ESMTP id m2H5TrtL002418 for ; Sun, 16 Mar 2008 21:29:54 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Date: Sun, 16 Mar 2008 21:29:53 -0800 (AKDT) From: peter stern To: freebsd-stable@freebsd.org Message-ID: <20080316211253.M2398@jago.65north.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: recovering from the 6.3 xorg mess 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, 17 Mar 2008 05:46:48 -0000 I'd appreciate suggestions on how to get a working xorg from the mess 6.3 shipped with. I've been using FreeBSD since 2.2 and have never had much trouble with it until the 6 branch was released. My hardware is pretty generic Intel brand D865 motherboard, matrox g550 video. I don't customize the kernel. I do clean installs not upgrades. The xorg in 6.3 doesn't install much in the way of required drivers. I got the mouse and keyboard drivers installed and also the mga driver. I have run xorgconfig to create what seems like a working xorg.conf. Startx brings up twm but only in 640x480. I cannot change modes. And yes, I have mode lines defined. If I put the correct horizontal and vertical scan rates in for my Viewsonic PT810 monitor, I get a screen display with lines precessing through it. xdm gives the same result. I have tried the other suggestions on configuring X in the FreeBSD handbook, including creating a basic xorg.conf. It tests okay but only in 640x480 and it has no modelines in the .conf. Adding modelines doesn't fix the problem. The initial install was done by sysinstall under the predefined xdeveloper selection. I tried reinstalling xorg from ports by running make deinstall and make reinstall but with no change in behavior. My hardware has no problems running Slackware 12 or Openbsd 4.2. Under those OSs, X11 works fine and configures without problems. What has happened to quality control in the FreeBSD release? peter From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 06:36:27 2008 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 99996106564A for ; Mon, 17 Mar 2008 06:36:27 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (unknown [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 57ED58FC1F for ; Mon, 17 Mar 2008 06:36:27 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jb8xL-0007Ol-HF; Mon, 17 Mar 2008 07:36:23 +0100 Date: Mon, 17 Mar 2008 07:36:23 +0100 From: Kurt Jaeger To: peter stern Message-ID: <20080317063623.GA3180@home.opsec.eu> References: <20080316211253.M2398@jago.65north.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080316211253.M2398@jago.65north.com> Cc: freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 06:36:27 -0000 Hi! > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > shipped with. I've been using FreeBSD since 2.2 and have never had much > trouble with it until the 6 branch was released. My hardware is pretty > generic Intel brand D865 motherboard, matrox g550 video. I don't customize > the kernel. I do clean installs not upgrades. Basically, the problem is with the matrox board. Due to the very same reasons I had to upgrade my workstation (good excuse 8-) Matrox provides a mga_hal binary to support the relevant resolution and other gimmicks of that board. This binary works with xorg-6.x, but not with xorg-7.x, because there were changes in the interfaces to the low-level things. As far as I can see, there is no driver from mga for 7.x available as of now. -- pi@opsec.eu +49 171 3101372 12 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 06:56:04 2008 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 CB0961065670 for ; Mon, 17 Mar 2008 06:56:04 +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 33D0E8FC1B for ; Mon, 17 Mar 2008 06:56:03 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (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 m2H6tw1o064661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 17:25:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 17 Mar 2008 17:25:50 +1030 User-Agent: KMail/1.9.7 References: <20080316211253.M2398@jago.65north.com> In-Reply-To: <20080316211253.M2398@jago.65north.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1418595.tzQZqQrfuU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200803171725.51685.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: peter stern Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 06:56:04 -0000 --nextPart1418595.tzQZqQrfuU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 17 Mar 2008, peter stern wrote: > The initial install was done by sysinstall under the predefined > xdeveloper selection. I tried reinstalling xorg from ports by running > make deinstall and make reinstall but with no change in behavior. Where is your dmesg, /var/log/Xorg.0.log, and X config file? A listing of /var/db/pkg would be helpful to show what X ports you have=20 installed. > My hardware has no problems running Slackware 12 or Openbsd 4.2. > Under those OSs, X11 works fine and configures without problems. > > What has happened to quality control in the FreeBSD release? Well *I* didn't have any problem running X on 6.3 release. Maybe you=20 should have contributed by downloading an RC and testing it? G550's are very old cards, I don't think it's unreasonable to expect=20 that someone doing RC testing would have one installed. =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 --nextPart1418595.tzQZqQrfuU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBH3hX35ZPcIHs/zowRAk5RAJ9VKUYS5eNKvmFlBFxkBvduBn2STgCfUicr DHSAsVbeyk99ZyS0DGyRfqU= =IGuu -----END PGP SIGNATURE----- --nextPart1418595.tzQZqQrfuU-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 07:04:53 2008 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 2AEBD106566C for ; Mon, 17 Mar 2008 07:04:53 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id EF2218FC17 for ; Mon, 17 Mar 2008 07:04:52 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so3443228rvb.43 for ; Mon, 17 Mar 2008 00:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=u/eCaELvl0EdP1kH52pGkSkLyUpX0eXsXLYEB+G80KQ=; b=l08z//c4Z1kKyvuytGsGn60i0uSKZF6tw7N6fibs+BJRPNBTq64+XPPREkKWBRSCsxf5LCIThfI1Dyoi0Nmq6o7m8l1rifyFyPnaxTbG5QF+VrTVeDUaX6ZAbGFTyZg4/SBnW9XeUxh0F1OI4X6PxNCd1k+e0WW3/+d1U7GPo8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KC/bbFeC9UTkLXVQ6M1OiZGhAbaU9Id9/Bqv0mYfjw/ijiUTzRrrB0PfDNdTIdSgxYVSaCwCwMFJZQbdZkxJ2gVH/Jy1v0KP5mKkieaUiow1/yeG53bjcjwqLzw7veuMkkKKAjf88H8ik2Zb74Eh2II3nR2rn/vXNWK819I6K1s= Received: by 10.141.141.3 with SMTP id t3mr7292826rvn.226.1205735931984; Sun, 16 Mar 2008 23:38:51 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Sun, 16 Mar 2008 23:38:51 -0700 (PDT) Message-ID: <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> Date: Mon, 17 Mar 2008 06:38:51 +0000 From: "Brad Pitney" To: "peter stern" In-Reply-To: <20080316211253.M2398@jago.65north.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080316211253.M2398@jago.65north.com> Cc: freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 07:04:53 -0000 On Mon, Mar 17, 2008 at 5:29 AM, peter stern wrote: > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > shipped with. I've been using FreeBSD since 2.2 and have never had much > trouble with it until the 6 branch was released. My hardware is pretty > generic Intel brand D865 motherboard, matrox g550 video. I don't customize > the kernel. I do clean installs not upgrades. > have you tried without an xorg.conf? > The xorg in 6.3 doesn't install much in the way of required drivers. I got > the mouse and keyboard drivers installed and also the mga driver. I have > run xorgconfig to create what seems like a working xorg.conf. Startx > brings up twm but only in 640x480. I cannot change modes. And yes, I have > mode lines defined. If I put the correct horizontal and vertical scan > rates in for my Viewsonic PT810 monitor, I get a screen display with lines > precessing through it. xdm gives the same result. > > I have tried the other suggestions on configuring X in the FreeBSD > handbook, including creating a basic xorg.conf. It tests okay but only in > 640x480 and it has no modelines in the .conf. Adding modelines doesn't fix > the problem. > I suspect modelines won't help and there might be a bug in xf86-video-mga? > The initial install was done by sysinstall under the predefined > xdeveloper selection. I tried reinstalling xorg from ports by running make > deinstall and make reinstall but with no change in behavior. > what about installing just base then using an up-to-date ports? > My hardware has no problems running Slackware 12 or Openbsd 4.2. Under > those OSs, X11 works fine and configures without problems. > > What has happened to quality control in the FreeBSD release? is it really a FreeBSD issue? > > peter > -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 07:33:28 2008 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 84324106564A for ; Mon, 17 Mar 2008 07:33:28 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id 38B818FC31 for ; Mon, 17 Mar 2008 07:33:27 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (core.stromnet.se [83.218.84.131]) by core.stromnet.se (Postfix) with ESMTP id 098BBD4640C; Mon, 17 Mar 2008 08:32:58 +0100 (CET) X-Virus-Scanned: amavisd-new at stromnet.se Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.135]) (amavisd-new, port 10024) with ESMTP id 7DGtaixmrjF5; Mon, 17 Mar 2008 08:32:53 +0100 (CET) Received: from johan-mp.stromnet.se (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id C0B7DD46405; Mon, 17 Mar 2008 08:32:53 +0100 (CET) Message-Id: <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> From: =?ISO-8859-1?Q?Johan_Str=F6m?= To: ulf@Alameda.net In-Reply-To: <20080316073616.GQ87650@evil.alameda.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 08:33:20 +0100 References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 07:33:28 -0000 On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: > On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: >> Johan Str?m wrote: >>> But.. >>> http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf >>> seems >>> to tell me that in basic mode I can only access BIOS (pre-OS) >>> using the >>> Remote Console feature, and that after POST I have to have the >>> advanced >>> licensed option? >>> >> >> I don't do the purchasing and we get all Advanced iLO, so I will take >> your word for it. The older generations supported text console (i >> have >> a 360G2 that does so). We use the HP Management agents under >> Windows >> for all SNMP reporting so I can't comment on the reporting method >> under >> other OS's. > > iLO2 ActiveX based remote console (Integrated KVM) can still do > text only console without license but it doesn't work too well IMHO. > The Java based console is the same, text will work out license but > graphics > mode and that includes certain VESA text modes. > > Standard iLO gives the graphical console and virtual media. On Blade > servers > the graphical access and virtual media is included. And the Advanced > license > gives extra stuff like integration into AD for authentication afik. How about SSH mode? SSH and view textmode at boot (serial rdr in bios too?) and console @ serial in fbsd (bootloader and on). Does that work good or "not to well" either? Lets hope it works out good now at least, I ordered the box, without full license though, but I guess I can always get that later on if it turns out to work like crap.. But for once I'm purchasing quality brand hardware.. So it should work with me instead of against me... I hope :) Thank you all for all of your replies! From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 08:11:33 2008 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 51FB31065670 for ; Mon, 17 Mar 2008 08:11:33 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.249]) by mx1.freebsd.org (Postfix) with ESMTP id ECECD8FC18 for ; Mon, 17 Mar 2008 08:11:32 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: by hs-out-0708.google.com with SMTP id m63so4425826hsc.11 for ; Mon, 17 Mar 2008 01:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc:references:in-reply-to:subject:date:organization:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id; bh=hRsmlLwvs0CeBqRgV5ZV0F+8C6b2WhBUAly6yqp1Vec=; b=psZpdDgaXTAxzCcs54SRcLvbRCqDeufyVhR2Rtu8ZGzx6LA9Voc/Ex3CxO6XzcigZFdscqVV4KR24OVaDnJwQu94f33BJMj4+23l2n9YX2oc9w3yGt2DHUwBD//LheuilC6105N9uAHmia93st+Ooz6lm9EwaY0XdBF2emhDXWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:organization:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id; b=evurzvg2XXbxcNNfGrPgp+DjLjC9qAwDWMnH953luq2WNULbmWpEloDYYt8NKskTBED6GNuOf9kVARfL9wBHu4DWTHAuyGTgU/t8vpuhWdsEVm6XnEvbpCZbbChizviOT0e4qc1sP/YyWMaxePWNIlLkTCyRA+Wy2jmyBHqWF1U= Received: by 10.100.255.10 with SMTP id c10mr31874844ani.3.1205739831157; Mon, 17 Mar 2008 00:43:51 -0700 (PDT) Received: from Avalon ( [119.77.64.182]) by mx.google.com with ESMTPS id c38sm21143211anc.31.2008.03.17.00.43.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Mar 2008 00:43:50 -0700 (PDT) From: "Robert Chalmers" To: "'Brad Pitney'" , "'peter stern'" References: <20080316211253.M2398@jago.65north.com> <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> In-Reply-To: <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> Date: Mon, 17 Mar 2008 17:43:27 +1000 Organization: China Lights MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciH/VTYI8nkdvVzSWm90kUJOZmoiQAA+GQw Content-Language: en-au Message-ID: <47de2136.261d640a.1c5a.66d2@mx.google.com> Cc: freebsd-stable@freebsd.org Subject: RE: recovering from the 6.3 xorg mess X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: robert@chalmers.com.au List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 08:11:33 -0000 Well, I suppose this will eventually get to the original poster. I too have just gone through this nightmare. But, I short circuited it all. I went to a clean install of 7.0-RELEASE. Ah ha. Easy. Nope. The gremlins were waiting. So basically here's what I did. When I loaded the new system, I installed EVERYTHING I could enable. If there was an option, I installed it. Beautiful. Rebooted - X blah blah blah .... of course not. Fiddled with the xogconfig and made lots of xorg.config attempts, then realised - looking at the log - that it couldn't find the S3 driver. Yes, ancient S3 card in this box. All of 8 years old. So - took a clue from the log, and went into I think, like, ....xorg-drivers, and looked at the Makefile, which had everything in it. I commented out the things I would never need - mouses, and video - which is all that is in there, and left in the obvious ones, including some that "might come in handy one day" and typed Make install clean Now it all works. Well, as soon as I figure out some of the other mystical incantations - worse than World of War this lot. But bottom lline. Go into that xorg-driveers directory and check the Makefile, then "make install clean" and lots of things start happening. And I add - this is after a clean install where I said "Just do it" ... yea right. :-) Sorry I can't check those directories - I'm currently trying to port in VNC .... I live in hope. Robert -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Brad Pitney Sent: Monday, 17 March 2008 4:39 PM To: peter stern Cc: freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess On Mon, Mar 17, 2008 at 5:29 AM, peter stern wrote: > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > shipped with. I've been using FreeBSD since 2.2 and have never had much > trouble with it until the 6 branch was released. My hardware is pretty > generic Intel brand D865 motherboard, matrox g550 video. I don't customize > the kernel. I do clean installs not upgrades. > have you tried without an xorg.conf? > The xorg in 6.3 doesn't install much in the way of required drivers. I got > the mouse and keyboard drivers installed and also the mga driver. I have > run xorgconfig to create what seems like a working xorg.conf. Startx > brings up twm but only in 640x480. I cannot change modes. And yes, I have > mode lines defined. If I put the correct horizontal and vertical scan > rates in for my Viewsonic PT810 monitor, I get a screen display with lines > precessing through it. xdm gives the same result. > > I have tried the other suggestions on configuring X in the FreeBSD > handbook, including creating a basic xorg.conf. It tests okay but only in > 640x480 and it has no modelines in the .conf. Adding modelines doesn't fix > the problem. > I suspect modelines won't help and there might be a bug in xf86-video-mga? > The initial install was done by sysinstall under the predefined > xdeveloper selection. I tried reinstalling xorg from ports by running make > deinstall and make reinstall but with no change in behavior. > what about installing just base then using an up-to-date ports? > My hardware has no problems running Slackware 12 or Openbsd 4.2. Under > those OSs, X11 works fine and configures without problems. > > What has happened to quality control in the FreeBSD release? is it really a FreeBSD issue? > > peter > -- Best regards, Brad _______________________________________________ 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 Mon Mar 17 08:52:41 2008 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 F3DCB106564A for ; Mon, 17 Mar 2008 08:52:40 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id CBB8F8FC1C for ; Mon, 17 Mar 2008 08:52:40 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id CEF801CC060; Mon, 17 Mar 2008 01:52:40 -0700 (PDT) Date: Mon, 17 Mar 2008 01:52:40 -0700 From: Jeremy Chadwick To: Johan =?iso-8859-1?Q?Str=F6m?= Message-ID: <20080317085240.GA40391@eos.sc1.parodius.com> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org, ulf@Alameda.net Subject: Re: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 08:52:41 -0000 On Mon, Mar 17, 2008 at 08:33:20AM +0100, Johan Ström wrote: > On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: > >> On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: >>> Johan Str?m wrote: >>>> But.. >>>> http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf >>>> seems >>>> to tell me that in basic mode I can only access BIOS (pre-OS) using the >>>> Remote Console feature, and that after POST I have to have the advanced >>>> licensed option? >>>> >>> >>> I don't do the purchasing and we get all Advanced iLO, so I will take >>> your word for it. The older generations supported text console (i have >>> a 360G2 that does so). We use the HP Management agents under Windows >>> for all SNMP reporting so I can't comment on the reporting method under >>> other OS's. >> >> iLO2 ActiveX based remote console (Integrated KVM) can still do >> text only console without license but it doesn't work too well IMHO. >> The Java based console is the same, text will work out license but >> graphics >> mode and that includes certain VESA text modes. >> >> Standard iLO gives the graphical console and virtual media. On Blade >> servers >> the graphical access and virtual media is included. And the Advanced >> license >> gives extra stuff like integration into AD for authentication afik. > > How about SSH mode? SSH and view textmode at boot (serial rdr in bios too?) > and console @ serial in fbsd (bootloader and on). Does that work good or > "not to well" either? I have to chime in here. Who cares if it has SSH support? iLO, LOM, and serial console should all be done over a *private network*, and should NOT be hooked up to a publicly-accessible network or given public IPs. I cannot stress how important this is. DO NOT put stuff like this on the public Internet: you will regret it. The advantage to iLO is that it's the equivalent of KVM-over-IP, supporting virtual media too (read: an ISO image on your laptop/local client machine being used as a CD on the server itself, thus you can install whatever OS you want, etc.). You get NATIVE VGA CONSOLE remotely on the machine -- there is no "serial console", and that's always best. I've seen it in action, and it's *awesome*. Said iLO capability usually works over a series of TCP or UDP ports, somtimes even supporting HTTP (on the iLO module itself!) which means if its on a private network, you can tunnel to it using SSH or similar utilities via another box in the co-lo. Then simply access 127.0.0.1:whatever in the ActiveX, Java, or native Win32/Linux client and voila -- you have the machines' native VGA console in front of you, with no issues relating to serial console. No more "ohhh, the bootup configuration uses 9600bps, but our serial console servers are configured to use 115200bps... but the disk isn't booting so it's still using 9600bps at that stage, now I HAVE to go to the datacenter" scenarios. I do not trust IPMI based on stories I have heard from Yahoo! SAs, talking about how every implementation is different (so much for a "standard"), and how the number of bugs in Supermicro's IPMI implementation are absurd. Supposedly Intel and others have done a better job with it, but I lost all interest in it once I found that there was no real "standard". Besides, anything that "piggybacks" on top of an existing LAN port (even some iLO implementations do this!) is worth avoiding. I do not want to deal with a single NIC emitting two separate MAC addresses -- and that's what happens. It's sometimes referred to as "ASF" as well. Serial console is a major hassle -- and that comment is coming from someone who has quite a bit of experience with it, and relies on it on a daily basis. It's very disappointing that iLO-like capabilities have not become standard in PC hardware these days. Instead, there's a "market" for it, when there should be none. It's a necessity in this day and age. The only company to have done it right on x86 from the get-go seems to be Compaq/HP. Rant over. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 10:46:33 2008 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 58D5E1065673 for ; Mon, 17 Mar 2008 10:46:33 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3BD8FC2A for ; Mon, 17 Mar 2008 10:46:32 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id A012333D3E; Mon, 17 Mar 2008 03:46:28 -0700 (PDT) Date: Mon, 17 Mar 2008 03:46:28 -0700 From: Ulf Zimmermann To: Johan Str?m Message-ID: <20080317104628.GA98129@evil.alameda.net> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-stable@freebsd.org, ulf@Alameda.net Subject: Re: HP ProLiant DL360 G5 success stories? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 10:46:33 -0000 On Mon, Mar 17, 2008 at 08:33:20AM +0100, Johan Str?m wrote: > On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: > > >On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: > >>Johan Str?m wrote: > >>>But.. > >>>http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > >>> seems > >>>to tell me that in basic mode I can only access BIOS (pre-OS) > >>>using the > >>>Remote Console feature, and that after POST I have to have the > >>>advanced > >>>licensed option? > >>> > >> > >>I don't do the purchasing and we get all Advanced iLO, so I will take > >>your word for it. The older generations supported text console (i > >>have > >>a 360G2 that does so). We use the HP Management agents under > >>Windows > >>for all SNMP reporting so I can't comment on the reporting method > >>under > >>other OS's. > > > >iLO2 ActiveX based remote console (Integrated KVM) can still do > >text only console without license but it doesn't work too well IMHO. > >The Java based console is the same, text will work out license but > >graphics > >mode and that includes certain VESA text modes. > > > >Standard iLO gives the graphical console and virtual media. On Blade > >servers > >the graphical access and virtual media is included. And the Advanced > >license > >gives extra stuff like integration into AD for authentication afik. > > How about SSH mode? SSH and view textmode at boot (serial rdr in bios > too?) and console @ serial in fbsd (bootloader and on). Does that work > good or "not to well" either? > Lets hope it works out good now at least, I ordered the box, without > full license though, but I guess I can always get that later on if it > turns out to work like crap.. But for once I'm purchasing quality > brand hardware.. So it should work with me instead of against me... I > hope :) > > Thank you all for all of your replies! iLO1 (used on DL360 g3, g4, g4p and DL380 g3, g4) had text console via ssh and I have used it often because of cut+paste. Unfortunatly as far I know iLO2 (used on g5) does not support ssh text console. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 10:56:41 2008 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 8066C106566B; Mon, 17 Mar 2008 10:56:41 +0000 (UTC) (envelope-from freebsd-stable@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5648FC15; Mon, 17 Mar 2008 10:56:41 +0000 (UTC) (envelope-from freebsd-stable@epcdirect.co.uk) Received: from localhost (localhost.epcdirect.co.uk [127.0.0.1]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 949E762C0; Mon, 17 Mar 2008 10:38:28 +0000 (GMT) X-Virus-Scanned: by GunFright.EPCDirect.co.uk Received: from gunfright.epcdirect.co.uk ([127.0.0.1]) by localhost (gunfright.epcdirect.co.uk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q4WY-LzZPA9S; Mon, 17 Mar 2008 10:38:28 +0000 (GMT) Received: from lfarr (l-farr.int.epcdirect.co.uk [192.168.6.200]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 47D4A62BE; Mon, 17 Mar 2008 10:38:28 +0000 (GMT) From: "Lawrence Farr" To: "'John Baldwin'" , References: <200803141546.10569.jhb@freebsd.org> In-Reply-To: <200803141546.10569.jhb@freebsd.org> Date: Mon, 17 Mar 2008 10:38:24 -0000 Message-ID: <01fc01c8881b$075b5620$16120260$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciGDR47Y/5pOBB0Tr+MaPvuEpvj/QCDM30w Content-Language: en-gb Cc: Subject: RE: bin/121684: dump frequently hangs 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, 17 Mar 2008 10:56:41 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of John Baldwin > Sent: 14 March 2008 19:46 > To: freebsd-stable@freebsd.org > Cc: Greg Rivers > Subject: Re: bin/121684: dump frequently hangs > > On Friday 14 March 2008 12:53:22 am Greg Rivers wrote: > > I'm seeing dump hang frequently on RELENG_7 i386. Details and a > ktrace in > > PR bin/121684. Is anyone else experiencing this? > > jeff@ just fixed this in HEAD with the latest patch to > sys/kern/subr_sleepqueue.c. The patch should apply directly to > RELENG_7. I couldn't get this to apply cleanly against 7, is it safe to use rev 1.48 on 7? I have 3 machines here that hang whilst dumping and I'd like to test the patch. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 11:06:36 2008 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 9E90A106567D for ; Mon, 17 Mar 2008 11:06:36 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id 3464B8FC22 for ; Mon, 17 Mar 2008 11:06:35 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (core.stromnet.se [83.218.84.131]) by core.stromnet.se (Postfix) with ESMTP id 1DD96D4640F; Mon, 17 Mar 2008 12:06:07 +0100 (CET) X-Virus-Scanned: amavisd-new at stromnet.se Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.135]) (amavisd-new, port 10024) with ESMTP id u9Hq0xStOjYc; Mon, 17 Mar 2008 12:05:59 +0100 (CET) Received: from johan-mp.stromnet.se (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id B1AA3D4640C; Mon, 17 Mar 2008 12:05:59 +0100 (CET) Message-Id: <3ACAC3A7-F921-4C2D-8D97-35C9395FBFD4@stromnet.se> From: =?ISO-8859-1?Q?Johan_Str=F6m?= To: ulf@Alameda.net In-Reply-To: <20080317104628.GA98129@evil.alameda.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 12:06:27 +0100 References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> <20080317104628.GA98129@evil.alameda.net> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 11:06:36 -0000 On Mar 17, 2008, at 11:46 AM, Ulf Zimmermann wrote: > On Mon, Mar 17, 2008 at 08:33:20AM +0100, Johan Str?m wrote: >> On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: >> >>> On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: >>>> Johan Str?m wrote: >>>>> But.. >>>>> http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf >>>>> seems >>>>> to tell me that in basic mode I can only access BIOS (pre-OS) >>>>> using the >>>>> Remote Console feature, and that after POST I have to have the >>>>> advanced >>>>> licensed option? >>>>> >>>> >>>> I don't do the purchasing and we get all Advanced iLO, so I will >>>> take >>>> your word for it. The older generations supported text console (i >>>> have >>>> a 360G2 that does so). We use the HP Management agents under >>>> Windows >>>> for all SNMP reporting so I can't comment on the reporting method >>>> under >>>> other OS's. >>> >>> iLO2 ActiveX based remote console (Integrated KVM) can still do >>> text only console without license but it doesn't work too well IMHO. >>> The Java based console is the same, text will work out license but >>> graphics >>> mode and that includes certain VESA text modes. >>> >>> Standard iLO gives the graphical console and virtual media. On Blade >>> servers >>> the graphical access and virtual media is included. And the Advanced >>> license >>> gives extra stuff like integration into AD for authentication afik. >> >> How about SSH mode? SSH and view textmode at boot (serial rdr in bios >> too?) and console @ serial in fbsd (bootloader and on). Does that >> work >> good or "not to well" either? >> Lets hope it works out good now at least, I ordered the box, without >> full license though, but I guess I can always get that later on if it >> turns out to work like crap.. But for once I'm purchasing quality >> brand hardware.. So it should work with me instead of against me... I >> hope :) >> >> Thank you all for all of your replies! > > iLO1 (used on DL360 g3, g4, g4p and DL380 g3, g4) had text console > via ssh and I have used it often because of cut+paste. Unfortunatly > as far I know iLO2 (used on g5) does not support ssh text console. Hm.. No not native text console, but the virtual serial port should work under SSH if I'm reading the manual correct: " Although additional configuration steps are required to use Remote Serial Console (as compared to using the remote console or IRC), the Remote Serial Console allows telnet or SSH users to interact with the server remotely and without requiring an iLO 2 Advanced license and is the only way a true text-based remote console is presented by iLO 2. " If I've understood correct, the "text console" mode from iLO 1 is removed all together in favor for graphical mode (the internal workings have been changed). From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 11:16:18 2008 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 62891106566B for ; Mon, 17 Mar 2008 11:16:18 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from core.stromnet.se (core.stromnet.se [83.218.84.131]) by mx1.freebsd.org (Postfix) with ESMTP id A0AA18FC1C for ; Mon, 17 Mar 2008 11:16:17 +0000 (UTC) (envelope-from johan@stromnet.se) Received: from localhost (core.stromnet.se [83.218.84.131]) by core.stromnet.se (Postfix) with ESMTP id DA6CDD4640C; Mon, 17 Mar 2008 12:15:48 +0100 (CET) X-Virus-Scanned: amavisd-new at stromnet.se Received: from core.stromnet.se ([83.218.84.131]) by localhost (core.stromnet.se [83.218.84.135]) (amavisd-new, port 10024) with ESMTP id vHj1fpc19FYz; Mon, 17 Mar 2008 12:15:42 +0100 (CET) Received: from johan-mp.stromnet.se (90-224-172-102-no129.tbcn.telia.com [90.224.172.102]) by core.stromnet.se (Postfix) with ESMTP id AEF06D46405; Mon, 17 Mar 2008 12:15:42 +0100 (CET) Message-Id: <7982C43A-4252-46EC-9FA1-5AE78CFD88B0@stromnet.se> From: =?ISO-8859-1?Q?Johan_Str=F6m?= To: Jeremy Chadwick In-Reply-To: <20080317085240.GA40391@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 12:16:10 +0100 References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> <20080317085240.GA40391@eos.sc1.parodius.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 11:16:18 -0000 On Mar 17, 2008, at 9:52 AM, Jeremy Chadwick wrote: > On Mon, Mar 17, 2008 at 08:33:20AM +0100, Johan Str=F6m wrote: >> On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: >> >>> On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: >>>> Johan Str?m wrote: >>>>> But.. >>>>> = http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c0= 0553302.pdf >>>>> seems >>>>> to tell me that in basic mode I can only access BIOS (pre-OS) =20 >>>>> using the >>>>> Remote Console feature, and that after POST I have to have the =20 >>>>> advanced >>>>> licensed option? >>>>> >>>> >>>> I don't do the purchasing and we get all Advanced iLO, so I will =20= >>>> take >>>> your word for it. The older generations supported text console =20 >>>> (i have >>>> a 360G2 that does so). We use the HP Management agents under =20 >>>> Windows >>>> for all SNMP reporting so I can't comment on the reporting method =20= >>>> under >>>> other OS's. >>> >>> iLO2 ActiveX based remote console (Integrated KVM) can still do >>> text only console without license but it doesn't work too well IMHO. >>> The Java based console is the same, text will work out license but >>> graphics >>> mode and that includes certain VESA text modes. >>> >>> Standard iLO gives the graphical console and virtual media. On Blade >>> servers >>> the graphical access and virtual media is included. And the Advanced >>> license >>> gives extra stuff like integration into AD for authentication afik. >> >> How about SSH mode? SSH and view textmode at boot (serial rdr in =20 >> bios too?) >> and console @ serial in fbsd (bootloader and on). Does that work =20 >> good or >> "not to well" either? > > I have to chime in here. > > Who cares if it has SSH support? iLO, LOM, and serial console should > all be done over a *private network*, and should NOT be hooked up to a > publicly-accessible network or given public IPs. I cannot stress how > important this is. DO NOT put stuff like this on the public Internet: > you will regret it. > > > The advantage to iLO is that it's the equivalent of KVM-over-IP, > supporting virtual media too (read: an ISO image on your laptop/local > client machine being used as a CD on the server itself, thus you can > install whatever OS you want, etc.). You get NATIVE VGA CONSOLE > remotely on the machine -- there is no "serial console", and that's > always best. I've seen it in action, and it's *awesome*. For advanced license yes. Thats another $400 or so (which might not be =20= very much money for big corps but for me and my one server =20 installation its more..) > > > Said iLO capability usually works over a series of TCP or UDP ports, > somtimes even supporting HTTP (on the iLO module itself!) which =20 > means if > its on a private network, you can tunnel to it using SSH or similar > utilities via another box in the co-lo. Then simply access > 127.0.0.1:whatever in the ActiveX, Java, or native Win32/Linux client > and voila -- you have the machines' native VGA console in front of =20 > you, > with no issues relating to serial console. No more "ohhh, the bootup > configuration uses 9600bps, but our serial console servers are > configured to use 115200bps... but the disk isn't booting so it's =20 > still > using 9600bps at that stage, now I HAVE to go to the datacenter" > scenarios. Yep, there are some downsides with serial console. But if it works, =20 i'd rather use a normal ssh client in my terminal together with the =20 virtual serial port than sitting in a web browser. But i'll guess I'm =20= going to evaluate the serial port option when I get the box, and if it =20= isnt working to good i'll just have to throw up the money and get the =20= advanced license (even if i'd rather use that money on more "fun" =20 things..) > > > I do not trust IPMI based on stories I have heard from Yahoo! SAs, > talking about how every implementation is different (so much for a > "standard"), and how the number of bugs in Supermicro's IPMI > implementation are absurd. Supposedly Intel and others have done a > better job with it, but I lost all interest in it once I found that > there was no real "standard". Besides, anything that "piggybacks" on > top of an existing LAN port (even some iLO implementations do this!) =20= > is > worth avoiding. I do not want to deal with a single NIC emitting two > separate MAC addresses -- and that's what happens. It's sometimes > referred to as "ASF" as well. I've got a supermicro ipmi card now and.. I'm afraid I cannot describe =20= it with better words than "crappy toy".. Constant IPMI card restarts/=20 crashes, the serial consol java browser applet stopping responding, =20 firmware upgrades that b0rks the card totally etc... -- Johan= From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 11:37:52 2008 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 748D5106566C for ; Mon, 17 Mar 2008 11:37:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 61A078FC28 for ; Mon, 17 Mar 2008 11:37:52 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 2AB231CC060; Mon, 17 Mar 2008 04:37:52 -0700 (PDT) Date: Mon, 17 Mar 2008 04:37:52 -0700 From: Jeremy Chadwick To: Johan =?iso-8859-1?Q?Str=F6m?= Message-ID: <20080317113752.GA44336@eos.sc1.parodius.com> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> <20080317085240.GA40391@eos.sc1.parodius.com> <7982C43A-4252-46EC-9FA1-5AE78CFD88B0@stromnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7982C43A-4252-46EC-9FA1-5AE78CFD88B0@stromnet.se> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 11:37:52 -0000 On Mon, Mar 17, 2008 at 12:16:10PM +0100, Johan Ström wrote: >> The advantage to iLO is that it's the equivalent of KVM-over-IP, >> supporting virtual media too (read: an ISO image on your laptop/local >> client machine being used as a CD on the server itself, thus you can >> install whatever OS you want, etc.). You get NATIVE VGA CONSOLE >> remotely on the machine -- there is no "serial console", and that's >> always best. I've seen it in action, and it's *awesome*. > > For advanced license yes. Thats another $400 or so (which might not be very > much money for big corps but for me and my one server installation its > more..) AFAIK, Advanced License will get you support for graphical/VESA/VGA modes, and provide virtual media. The standard iLO2 shipped with existing ProLiants should give you full VGA console (80x25) access, power-cycle capability, yadda yadda. Do you really need video support? The virtual media stuff is *really* cool, but it shouldn't be a problem to live without it. >> Said iLO capability usually works over a series of TCP or UDP ports, >> somtimes even supporting HTTP (on the iLO module itself!) which means if >> its on a private network, you can tunnel to it using SSH or similar >> utilities via another box in the co-lo. Then simply access >> 127.0.0.1:whatever in the ActiveX, Java, or native Win32/Linux client >> and voila -- you have the machines' native VGA console in front of you, >> with no issues relating to serial console. No more "ohhh, the bootup >> configuration uses 9600bps, but our serial console servers are >> configured to use 115200bps... but the disk isn't booting so it's still >> using 9600bps at that stage, now I HAVE to go to the datacenter" >> scenarios. > > Yep, there are some downsides with serial console. But if it works, i'd > rather use a normal ssh client in my terminal together with the virtual > serial port than sitting in a web browser. But i'll guess I'm going to > evaluate the serial port option when I get the box, and if it isnt working > to good i'll just have to throw up the money and get the advanced license > (even if i'd rather use that money on more "fun" things..) Okay, I understand. iLO2 provides serial-over-Ethernet, if I remember correctly. I forget how this works from a networking standpoint (if it's a TCP port you connect to, or if it's some custom protocol), but safe to say someone out there knows. :-) >> I do not trust IPMI based on stories I have heard from Yahoo! SAs, >> talking about how every implementation is different (so much for a >> "standard"), and how the number of bugs in Supermicro's IPMI >> implementation are absurd. Supposedly Intel and others have done a >> better job with it, but I lost all interest in it once I found that >> there was no real "standard". Besides, anything that "piggybacks" on >> top of an existing LAN port (even some iLO implementations do this!) is >> worth avoiding. I do not want to deal with a single NIC emitting two >> separate MAC addresses -- and that's what happens. It's sometimes >> referred to as "ASF" as well. > > I've got a supermicro ipmi card now and.. I'm afraid I cannot describe it > with better words than "crappy toy".. Constant IPMI card restarts/crashes, > the serial consol java browser applet stopping responding, firmware > upgrades that b0rks the card totally etc... I'm hearing you on FM! :-) You're the 4th or 5th person I've seen who has reported the exact same behaviour with Supermicro's IPMI cards. It makes me VERY glad that I did not shell out the extra cash for the IPMI add-on modules for our Supermicro boxes in our rack. IPMI is one of those things that's presented as a great idea (and it but the actual implementations done by vendors (or at least Supermicro) appears to be a complete mess. Very disappointing. Anyways, once you figure out the iLO2 stuff, be sure to send a mail describing how its working out for you. I've been very curious about it myself, since the last time I saw a ProLiant box, it was one which had an iLO add-on module (e.g. not integrated), and it was first-gen iLO. It was still VERY impressive, but I'm curious to know how things have matured. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 11:38:28 2008 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 208961065673 for ; Mon, 17 Mar 2008 11:38:28 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from angel.ticketswitch.com (angel.ticketswitch.com [IPv6:2002:57e0:1d4e::1]) by mx1.freebsd.org (Postfix) with ESMTP id DAEE88FC22 for ; Mon, 17 Mar 2008 11:38:27 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [10.50.50.2] (helo=smaug.rattatosk) by angel.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbDfc-000PYX-PL; Mon, 17 Mar 2008 11:38:24 +0000 Received: from dilbert.rattatosk ([10.50.50.6] helo=dilbert.ticketswitch.com) by smaug.rattatosk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbDfc-000O6o-NF; Mon, 17 Mar 2008 11:38:24 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbDfc-000MbY-Mg; Mon, 17 Mar 2008 11:38:24 +0000 To: doconnor@gsoft.com.au, freebsd-stable@freebsd.org In-Reply-To: <200803171725.51685.doconnor@gsoft.com.au> Message-Id: From: Pete French Date: Mon, 17 Mar 2008 11:38:24 +0000 Cc: pstern@65north.com Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 11:38:28 -0000 > G550's are very old cards, I don't think it's unreasonable to expect > that someone doing RC testing would have one installed. I missed the original posting, but I had a G550 (I think - may have been a 450, but I am fairly sure it was a 550) in my workstation here until a couple of weeks ago, and it ran fine under 6.3 and 7.0. The only slight niggle we had was having to disable the hardware mouse cursor as otherwise there was no pointerr - but this is well documented as a problem if you google for it. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 11:57:29 2008 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 1EEC81065672; Mon, 17 Mar 2008 11:57:29 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id D31908FC22; Mon, 17 Mar 2008 11:57:28 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (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 5640260E2; Mon, 17 Mar 2008 07:42:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1205754134; bh=q9AcbnXrAO9opw Ejm307C0f6vMfd6shkn1foPKU2NuM=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type; b=Y27Z6J3dGmw 75UAHkVsK+7R2ISI72Bt5snusc8tdQF8J0SdVsBxcMLWcABDBGeg7GaCLDRX3E3kjg4 8FJsbzz8DoKLpPWecdTZPJMnrYnl2BMlDcw80RafWp/7grXSfF 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; b=nauPm+GQ8YZSPvi+1X7x0l6H213vVdwhrKB8c2GdP3XnYnaFbJGwGT/gnEhmrhStX QbJFFMVX9RClZmkNSsn0hK6VR10R3S53G4g4JN76zZHo1BUxL88VJnSzPOu9E40 Message-ID: <47DE5915.50703@protected-networks.net> Date: Mon, 17 Mar 2008 07:42:13 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: Lawrence Farr References: <200803141546.10569.jhb@freebsd.org> <01fc01c8881b$075b5620$16120260$@co.uk> In-Reply-To: <01fc01c8881b$075b5620$16120260$@co.uk> X-Enigmail-Version: 0.95.6 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------060704070308050902000203" Cc: freebsd-stable@freebsd.org, 'John Baldwin' Subject: Re: bin/121684: dump frequently hangs 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, 17 Mar 2008 11:57:29 -0000 This is a multi-part message in MIME format. --------------060704070308050902000203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lawrence Farr wrote: > I couldn't get this to apply cleanly against 7, is it safe to use rev > 1.48 on 7? I have 3 machines here that hang whilst dumping and I'd > like to test the patch. For RELENG_7, I'm using the attached. Apply it from /usr, Michael --------------060704070308050902000203 Content-Type: text/x-patch; name="subr_sleepqueue.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="subr_sleepqueue.c.diff" *** src/sys/kern/subr_sleepqueue.c.orig Thu Mar 6 11:13:14 2008 --- src/sys/kern/subr_sleepqueue.c Fri Mar 14 21:58:58 2008 *************** *** 403,414 **** mtx_unlock(&ps->ps_mtx); } /* ! * Lock sleepq chain before unlocking proc ! * without this, we could lose a race. */ mtx_lock_spin(&sc->sc_lock); PROC_UNLOCK(p); thread_lock(td); if (ret == 0) { if (!(td->td_flags & TDF_INTERRUPT)) { sleepq_switch(wchan); --- 403,417 ---- mtx_unlock(&ps->ps_mtx); } /* ! * Lock the per-process spinlock prior to dropping the PROC_LOCK ! * to avoid a signal delivery race. PROC_LOCK, PROC_SLOCK, and ! * thread_lock() are currently held in tdsignal(). */ + PROC_SLOCK(p); mtx_lock_spin(&sc->sc_lock); PROC_UNLOCK(p); thread_lock(td); + PROC_SUNLOCK(p); if (ret == 0) { if (!(td->td_flags & TDF_INTERRUPT)) { sleepq_switch(wchan); --------------060704070308050902000203-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 12:48:03 2008 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 89B5C106566B for ; Mon, 17 Mar 2008 12:48:03 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb7:b8fe]) by mx1.freebsd.org (Postfix) with ESMTP id 021258FC23 for ; Mon, 17 Mar 2008 12:48:02 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id m2HCl1bw025695; Mon, 17 Mar 2008 13:47:02 +0100 From: Pieter de Goeje To: freebsd-stable@freebsd.org, robert@chalmers.com.au Date: Mon, 17 Mar 2008 13:47:01 +0100 User-Agent: KMail/1.9.7 References: <20080316211253.M2398@jago.65north.com> <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> <47de2136.261d640a.1c5a.66d2@mx.google.com> In-Reply-To: <47de2136.261d640a.1c5a.66d2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171347.01465.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 12:48:03 -0000 On Monday 17 March 2008, Robert Chalmers wrote: > Well, I suppose this will eventually get to the original poster. > > I too have just gone through this nightmare. But, I short circuited it all. > > I went to a clean install of 7.0-RELEASE. > > Ah ha. Easy. Nope. The gremlins were waiting. > > So basically here's what I did. > > When I loaded the new system, I installed EVERYTHING I could enable. If > there was an option, I installed it. > Beautiful. > Rebooted - X blah blah blah .... of course not. > Fiddled with the xogconfig and made lots of xorg.config attempts, then > realised - looking at the log - that it couldn't find the S3 driver. Yes, > ancient S3 card in this box. All of 8 years old. > So - took a clue from the log, and went into I think, like, > ....xorg-drivers, and looked at the Makefile, which had everything in it. I > commented out the things I would never need - mouses, and video - which is > all that is in there, and left in the obvious ones, including some that > "might come in handy one day" and typed > Make install clean > Now it all works. Well, as soon as I figure out some of the other mystical > incantations - worse than World of War this lot. > > But bottom lline. > Go into that xorg-driveers directory and check the Makefile, then "make > install clean" and lots of things start happening. > > > And I add - this is after a clean install where I said "Just do it" ... yea > right. :-) > > Sorry I can't check those directories - I'm currently trying to port in VNC > .... I live in hope. > Robert This is the reason why it is recommended to install x11/xorg. It will install all necessary drivers, servers, fonts and clients automatically. Installing x11-servers/xorg-server is not enough, because it doesn't install any drivers (it used to do this before Xorg 7 existed). -- Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 13:01:53 2008 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 C059F1065673 for ; Mon, 17 Mar 2008 13:01:53 +0000 (UTC) (envelope-from andy@agreenwood.dnsalias.com) Received: from smtp01.atlngahp.sys.nuvox.net (smtp-out1.atlngahp.sys.nuvox.net [70.43.63.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9A38FC30 for ; Mon, 17 Mar 2008 13:01:52 +0000 (UTC) (envelope-from andy@agreenwood.dnsalias.com) Received: from hercules.nuvox.net (216.215.202.5.nw.nuvox.net [216.215.202.5]) (authenticated bits=0) by smtp01.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with ESMTP id m2HCjrja012896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Mar 2008 08:45:54 -0400 Message-ID: <47DE680F.7040803@agreenwood.dnsalias.com> Date: Mon, 17 Mar 2008 08:46:07 -0400 From: Andy Greenwood User-Agent: Thunderbird 2.0.0.6 (X11/20071101) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <000e0cd28bfc044804ee5227d22ecd@google.com> <47D4BEC1.5000704@vintners.net> <47D54A4C.7080007@math.missouri.edu> <20080313185116.9ois3x6sgkocc4o0@webmail.1command.com> In-Reply-To: <20080313185116.9ois3x6sgkocc4o0@webmail.1command.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: list spam 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, 17 Mar 2008 13:01:53 -0000 Chris H. wrote: > Quoting Stephen Montgomery-Smith : > >> Mike Lempriere wrote: >>> I've had it with the list spam -- is the any possibility of >>> moderating this list, or changing it to must-be-subscriber-to-post? >>> >> >> >> I have the opposite experience. I am amazed at how little spam this >> list gets. So far today, only one piece of spam - from the ports list. > > I'd have to agree. I'm subscribed to several of the FBSD lists. Yet > in any 30 day period, the most I've received is less than 4. I'd > have to say, that's a pretty good ratio. :) > > --Chris H Same here. > >> >> _______________________________________________ >> 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 Mon Mar 17 16:29:51 2008 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 472251065676 for ; Mon, 17 Mar 2008 16:29:51 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailtwo.nsn.no [62.89.38.161]) by mx1.freebsd.org (Postfix) with SMTP id B2A258FC23 for ; Mon, 17 Mar 2008 16:29:50 +0000 (UTC) (envelope-from db@danielbond.org) Received: (qmail 35745 invoked by uid 0); 17 Mar 2008 16:03:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (85.95.44.187) by mail.nsn.no with SMTP; 17 Mar 2008 16:03:08 -0000 Message-ID: <47DE9638.6080609@danielbond.org> Date: Mon, 17 Mar 2008 17:03:04 +0100 From: Daniel Bond User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 OpenPGP: id=1A8DD04A; url=http://web.danielbond.org/pgp/danielbond-pubkey.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 17 Mar 2008 16:29:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, we use a large number of servers with centralized user-accounts in LDAP for ease of administration. The machines bind to LDAPv3 with TLS, and PAM accepts logins for ssh checking groupdn. This has been working great in FreeBSD 4.x, 5.x and 6.x, but while setting this up in FreeBSD 7.0-RELEASE (amd64) I ran into a few problems (tested on two machines). I've only used portsnap and portinstall to install packages (no pkg_add etc). I've also tried to recompile nss_ldap/pam_ldap/openldap-client and updating ldconfig. Brief description (config files etc further down): - ----- First I setup nss_ldap to list the users with "getent passwd", then I edited /etc/pam.d/sshd to allow logins. I *can login*, but in /var/log/auth.log I see one entry per login: Mar 17 16:36:05 webmail sshd[98863]: nss_ldap: could not get LDAP result - - Can't contact LDAP server Well, OK. I am logged in now. Time to break the setup (adding pam_mkhomedir): - ----- This is how my /etc/pam.d/sshd file looks like: # auth auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_ldap.so no_warn debug auth required pam_unix.so no_warn try_first_pass account required pam_nologin.so #account required /usr/local/lib/pam_ldap.so ignore_authinfo_unavail debug #usually enabled to enforce pam_groupdn in ldap.conf account required pam_login_access.so account required pam_unix.so # session session required pam_permit.so #session required /usr/local/lib/pam_mkhomedir.so skel=/etc/skel/sshd umask=0077 # password password required pam_unix.so no_warn try_first_pass Now, if I uncomment the line with pam_mkhomedir.so on it, logins stop to work. In /var/log/auth.log I now see two lines appearing: Mar 17 16:46:40 webmail sshd[98923]: nss_ldap: could not search LDAP server - Server is unavailable Mar 17 16:46:40 webmail sshd[98923]: error: PAM: pam_open_session(): error in service module I think this might be a problem in the PADL pam_ldap package, because I see some suspicious warnings while building it: cc -DHAVE_CONFIG_H -DLDAP_REFERRALS -DLDAP_DEPRECATED -DPIC - -D_REENTRANT -I/usr/local/include -O2 -fno-strict-aliasing -pipe - -Wall -fPIC -c pam_ldap.c pam_ldap.c: In function '_get_user_info': pam_ldap.c:2726: warning: passing argument 4 of '_get_long_integer_value' from incompatible pointer type pam_ldap.c: In function '_pam_ldap_get_session': pam_ldap.c:2741: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type pam_ldap.c: In function 'pam_sm_open_session': pam_ldap.c:3400: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type pam_ldap.c: In function 'pam_sm_chauthtok': pam_ldap.c:3466: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type pam_ldap.c:3477: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type pam_ldap.c:3619: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type pam_ldap.c: In function 'pam_sm_acct_mgmt': pam_ldap.c:3860: warning: passing argument 3 of 'pam_get_data' from incompatible pointer type If I add pam_mkhomedir.so to /etc/pam.d/su, I can su - and it creates my homedir. ~From ktracing it dosn't seem like sshd/pam isn't finding anything (well, it's not finding nss_dns.so, but I'm guessing that's not important). Has the PAM interface changed any in 7.0? Can anyone point me in the right direction to where the problem is, and how I can fix it (I don't know PAM internals and I'm not a great C-coder, but I'll give it a shot) ? I'm pretty sure my ldap.conf and nsswitch.conf are OK, but here they are anyway: /usr/local/etc/nss_ldap.conf -> openldap/ldap.conf /usr/local/etc/ldap.conf -> openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. base dc=nsn, dc=no HOST 1.slave.1881.int.nsn.no master.1881.int.nsn.no port 389 ldap_version 3 bind_policy soft binddn cn=unix7813,ou=sysusers,dc=nsn,dc=no bindpw ssl start_tls pam_filter objectclass=posixAccount pam_groupdn cn=mx-servers,ou=ssh-access,ou=groups,dc=nsn,dc=no pam_member_attribute member pam_password exop nss_base_passwd ou=nsnasa,ou=people,dc=nsn,dc=no nss_base_shadow ou=nsnasa,ou=people,dc=nsn,dc=no nss_base_group ou=posixgroups,ou=groups,dc=nsn,dc=no tls_checkpeer no TLS_REQCERT allow /etc/nsswitch.conf: group: files ldap hosts: files dns networks: files passwd: files ldap group_compat: nis passwd_compat: nis shells: files services: files protocols: files rpc: files I've tried a lot of different setups in this file, reversing orders, using *_compat etc.. So, If anyone has any theories, or something that can point me in any direction, I will greatly appreciate it. If I posted it to wrong forum, please point me to the correct/optimal forum. Otherwize I'm pleased to see the impressive new performance in 7.0, and better support for IBM Bladeservers and Qlogic 4gig FC-controllers :-) Great release! Thanks in advance. Kind regards, Daniel Bond. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3pY3UR3pKhqN0EoRAiedAJ0UK99P265XutZKb5dY5TY4siwfMgCeNDJs 6buxnV3WFV/G2cs6reBg0c0= =kVlJ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 16:44:10 2008 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 0B423106566B; Mon, 17 Mar 2008 16:44:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 4BCC58FC1C; Mon, 17 Mar 2008 16:44:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 235801822-1834499 for multiple; Mon, 17 Mar 2008 12:42:28 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m2HGi3qT078981; Mon, 17 Mar 2008 12:44:05 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-smp@freebsd.org Date: Mon, 17 Mar 2008 11:27:20 -0400 User-Agent: KMail/1.9.7 References: <20080315024114.GD67856@elvis.mu.org> In-Reply-To: <20080315024114.GD67856@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171127.20561.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]); Mon, 17 Mar 2008 12:44:05 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6275/Mon Mar 17 10:08:48 2008 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: stable@freebsd.org, Alfred Perlstein Subject: Re: timeout/untimeout race conditions/crash [patch] 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, 17 Mar 2008 16:44:10 -0000 On Friday 14 March 2008 10:41:14 pm Alfred Perlstein wrote: > We think we tracked down a defect in timeout/untimeout in > FreeBSD. > > We have reduced the problem to the following scenario: > > 2+ cpu system, one cpu is running softclock at the same time > another thread is running on another cpu which makes use of > timeout/untimeout. > > CPU 0 is running "softclock" > CPU 1 is running "driver" with Giant held. > > softclock: mtx_lock_spin(&callout_lock) > softclock: CACHES the callout structure's fields. > softclock: sees that it's a CALLOUT_LOCAL_ALLOC > softclock: executes this code: > if (c->c_flags & CALLOUT_LOCAL_ALLOC) { > c->c_func = NULL; > c->c_flags = CALLOUT_LOCAL_ALLOC; > SLIST_INSERT_HEAD(&callfree, c, > c_links.sle); > curr_callout = NULL; > } else { > > NOTE: that c->c_func has been set to NULL and curr_callout > is also NULL. > softclock: mtx_unlock_spin(&callout_lock) > driver: calls untimeout(), the following sequence happens: > mtx_lock_spin(&callout_lock); > if (handle.callout->c_func == ftn && handle.callout->c_arg == arg) > callout_stop(handle.callout); > mtx_unlock_spin(&callout_lock); > > NOTE: untimeout() sees that handle.callout->c_func is not set > to the function so it does NOT call callout_stop(9)! > driver: free's backing structure for c->c_arg. > softclock: executes callout. > softclock: likely crashes at this point due to access after free. > > I have a patch I'm trying out here, but I need feedback on it. > > The way the patch works is to treat CALLOUT_LOCAL_ALLOC (timeout/untimeout) > callouts the same as ~CALLOUT_LOCAL_ALLOC allocs, and moves the > freelist manipulation to the end of the callout dispatch. > > Some light testing seems to have the system work. > > We are doing some testing in-house to also make sure this works. > > Please provide feedback. > > See attached delta. This is not a bug. Don't use untimeout(9) as it is not guaranteed to be reliable. Instead, use callout_*(). Your patch doesn't solve any races as the driver detach routine needs to use callout_drain() and not just callout_stop/untimeout anyways. Fix your broken drivers. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 19:10:45 2008 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 48ACD106566C for ; Mon, 17 Mar 2008 19:10:45 +0000 (UTC) (envelope-from dave@syix.com) Received: from mail01.syix.com (mail01.syix.com [209.77.112.20]) by mx1.freebsd.org (Postfix) with ESMTP id 322D38FC26 for ; Mon, 17 Mar 2008 19:10:44 +0000 (UTC) (envelope-from dave@syix.com) Received: from localhost (localhost [127.0.0.1]) by mail01.syix.com (Postfix) with ESMTP id AFD7129B030 for ; Mon, 17 Mar 2008 11:50:57 -0700 (PDT) Received: from mail01.syix.com ([127.0.0.1]) by localhost (mail01.syix.com [127.0.0.1]) (amavisd-maia, port 10024) with LMTP id 69518-03-2 for ; Mon, 17 Mar 2008 11:50:55 -0700 (PDT) Received: from asian (asian.syix.com [209.77.113.38]) (Authenticated sender: dave) by mail01.syix.com (Postfix) with ESMTPA id 3603829B4AD for ; Mon, 17 Mar 2008 11:50:55 -0700 (PDT) From: "Dave Overton" To: Date: Mon, 17 Mar 2008 11:50:59 -0700 Organization: SYIX.COM Message-ID: <000e01c8885f$d78bc070$26714dd1@syix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciIX9dcrsmVgk/qT7KrkqYWkFpbxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: +rtfree: 0xffffff0003635780 has 1 refs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dave@syix.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:10:45 -0000 I am new to the AMD64 stable branch, so forgive me if this has been beat to death, but I can't find why this message keeps occurring over and over all day. FreeBSD 7.0 Stable on AMD x2. It works (or seems to) fine. +rtfree: 0xffffff0003635780 has 1 refs its a kernel "bold" on the terminal, and would scare me to death if I just knew what it meant... Should I be worried about something? I hate bold white text.... Dave Overton, Owner SYIX.COM dave@syix.com (530) 755-1751 x101 Fax (530) 751-8871 800-988-SYIX From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 19:55:12 2008 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 322411065676 for ; Mon, 17 Mar 2008 19:55:12 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id E414A8FC13 for ; Mon, 17 Mar 2008 19:55:11 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 3A4F01B10EF1; Mon, 17 Mar 2008 20:55:10 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [10.1.1.2] (unknown [192.168.25.10]) by blah.sun-fish.com (Postfix) with ESMTP id 158981B10EDC; Mon, 17 Mar 2008 20:55:04 +0100 (CET) Message-ID: <47DECC95.2030608@moneybookers.com> Date: Mon, 17 Mar 2008 21:55:01 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dave@syix.com References: <000e01c8885f$d78bc070$26714dd1@syix.com> In-Reply-To: <000e01c8885f$d78bc070$26714dd1@syix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6277/Mon Mar 17 19:08:59 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: +rtfree: 0xffffff0003635780 has 1 refs 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, 17 Mar 2008 19:55:12 -0000 Greetings Dave, Dave Overton wrote: > I am new to the AMD64 stable branch, so forgive me if this has been beat to > death, but I can't find why this message keeps occurring over and over all > day. FreeBSD 7.0 Stable on AMD x2. It works (or seems to) fine. > > +rtfree: 0xffffff0003635780 has 1 refs > check google for rtfree() used when RTFREE() needed .. or something like this :) Those messages are annoying but harmless. > its a kernel "bold" on the terminal, and would scare me to death if I just > knew what it meant... > > Should I be worried about something? I hate bold white text.... > > > > Dave Overton, Owner > SYIX.COM > > dave@syix.com > (530) 755-1751 x101 > Fax (530) 751-8871 > 800-988-SYIX > > _______________________________________________ > 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 Mon Mar 17 20:11:29 2008 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 E713A106564A; Mon, 17 Mar 2008 20:11:29 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D68498FC1A; Mon, 17 Mar 2008 20:11:29 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AE7C51A4D84; Mon, 17 Mar 2008 13:10:14 -0700 (PDT) Date: Mon, 17 Mar 2008 13:10:14 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20080317201014.GA67856@elvis.mu.org> References: <20080315024114.GD67856@elvis.mu.org> <200803171127.20561.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803171127.20561.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, freebsd-smp@freebsd.org Subject: Re: timeout/untimeout race conditions/crash [patch] 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, 17 Mar 2008 20:11:30 -0000 * John Baldwin [080317 09:43] wrote: > > This is not a bug. Don't use untimeout(9) as it is not guaranteed to be > reliable. Instead, use callout_*(). Your patch doesn't solve any races as > the driver detach routine needs to use callout_drain() and not just > callout_stop/untimeout anyways. Fix your broken drivers. I understand that some old Giant locked code can issue timeout/untimeout without Giant held, which would certainly cause this issue to happen and is uncorrectable, however, this is with completely Giant locked code. We are not trying to use timeout(9) for mpsafe code, this is old code and relies upon Giant. Giant locked code should be timeout/untimeout safe. As explained in my email, there exists a condition where the Giant locked code can have a timer fire even though proper Giant locking is observed. For a Giant locked subsystem, one should be able to have the following code work: mtx_lock(&Giant); /* formerly spl higher than softclock */ untimeout(&func, arg, &sc->handle); free(sc); mtx_unlock(&Giant); /* formerly splx() */ Normally splsoftclock would completely block the timeout from firing and this sort of code would be safe. It is no longer safe due to a BUG in the way that Giant is used. Please reread the original mail to better understand the synopsis of the problem. thank you, -Alfred From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 20:20:48 2008 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 B3DA1106567D for ; Mon, 17 Mar 2008 20:20:48 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from caillean.shopkeeper.de (caillean.shopkeeper.de [82.119.175.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6128FC2D for ; Mon, 17 Mar 2008 20:20:47 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (p54B87188.dip.t-dialin.net [84.184.113.136]) (authenticated bits=0) by caillean.shopkeeper.de (8.13.8/8.13.4) with ESMTP id m2HK5bS0083173 for ; Mon, 17 Mar 2008 21:05:40 +0100 (CET) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.2/8.12.11) with ESMTP id m2HK5XkU001121 for ; Mon, 17 Mar 2008 21:05:33 +0100 (CET) (envelope-from sascha@avalon.dobu.local) Received: (from sascha@localhost) by avalon.dobu.local (8.14.2/8.14.2/Submit) id m2HK5XmM001120 for freebsd-stable@freebsd.org; Mon, 17 Mar 2008 21:05:33 +0100 (CET) (envelope-from sascha) Date: Mon, 17 Mar 2008 21:05:33 +0100 From: Sascha Klauder To: freebsd-stable@freebsd.org Message-ID: <20080317200532.GA942@trimind.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.92.1/6261/Sun Mar 16 17:03:51 2008 on caillean.shopkeeper.de X-Virus-Status: Clean Subject: hifn(4) causing system lockup 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, 17 Mar 2008 20:20:48 -0000 Hi all, can someone comment on the state of the hifn(4) driver? I've recently upgraded my 6.2-STABLE workstation to RELENG_7, and I'm now experiencing system lockups that seem to be caused by the hifn(4) driver. I've got a Soekris vpn1401 card to help with GELI disk en- cryption. Reading from a GELI volume is causing the system to freeze completely, which does not happen if software crypto is used (i.e. hifn.ko not loaded). I can't enter kernel debugger (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu isn't up to par anyway. PR kern/92716, which is quite old already, describes somewhat similar symptoms. I had no such problems on the previous 6.2 install (dated from July 2007), and have verified that 6.3 shows the lockup behaviour as well. dmesg output available here: http://evenstar.shopkeeper.de/~sascha/avalon.dmesg7 Cheers, -sascha From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 21:34:50 2008 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 53EBF106566C for ; Mon, 17 Mar 2008 21:34:50 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 310F08FC13 for ; Mon, 17 Mar 2008 21:34:50 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id ED31B33D3E; Mon, 17 Mar 2008 14:34:44 -0700 (PDT) Date: Mon, 17 Mar 2008 14:34:44 -0700 From: Ulf Zimmermann To: Johan Str?m Message-ID: <20080317213444.GB98129@evil.alameda.net> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> <20080317104628.GA98129@evil.alameda.net> <3ACAC3A7-F921-4C2D-8D97-35C9395FBFD4@stromnet.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ACAC3A7-F921-4C2D-8D97-35C9395FBFD4@stromnet.se> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-stable@freebsd.org, ulf@Alameda.net Subject: Re: HP ProLiant DL360 G5 success stories? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 21:34:50 -0000 On Mon, Mar 17, 2008 at 12:06:27PM +0100, Johan Str?m wrote: > On Mar 17, 2008, at 11:46 AM, Ulf Zimmermann wrote: > > >On Mon, Mar 17, 2008 at 08:33:20AM +0100, Johan Str?m wrote: > >>On Mar 16, 2008, at 8:36 AM, Ulf Zimmermann wrote: > >> > >>>On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: > >>>>Johan Str?m wrote: > >>>>>But.. > >>>>>http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > >>>>>seems > >>>>>to tell me that in basic mode I can only access BIOS (pre-OS) > >>>>>using the > >>>>>Remote Console feature, and that after POST I have to have the > >>>>>advanced > >>>>>licensed option? > >>>>> > >>>> > >>>>I don't do the purchasing and we get all Advanced iLO, so I will > >>>>take > >>>>your word for it. The older generations supported text console (i > >>>>have > >>>>a 360G2 that does so). We use the HP Management agents under > >>>>Windows > >>>>for all SNMP reporting so I can't comment on the reporting method > >>>>under > >>>>other OS's. > >>> > >>>iLO2 ActiveX based remote console (Integrated KVM) can still do > >>>text only console without license but it doesn't work too well IMHO. > >>>The Java based console is the same, text will work out license but > >>>graphics > >>>mode and that includes certain VESA text modes. > >>> > >>>Standard iLO gives the graphical console and virtual media. On Blade > >>>servers > >>>the graphical access and virtual media is included. And the Advanced > >>>license > >>>gives extra stuff like integration into AD for authentication afik. > >> > >>How about SSH mode? SSH and view textmode at boot (serial rdr in bios > >>too?) and console @ serial in fbsd (bootloader and on). Does that > >>work > >>good or "not to well" either? > >>Lets hope it works out good now at least, I ordered the box, without > >>full license though, but I guess I can always get that later on if it > >>turns out to work like crap.. But for once I'm purchasing quality > >>brand hardware.. So it should work with me instead of against me... I > >>hope :) > >> > >>Thank you all for all of your replies! > > > >iLO1 (used on DL360 g3, g4, g4p and DL380 g3, g4) had text console > >via ssh and I have used it often because of cut+paste. Unfortunatly > >as far I know iLO2 (used on g5) does not support ssh text console. > > Hm.. No not native text console, but the virtual serial port should > work under SSH if I'm reading the manual correct: > > " > Although additional configuration steps are required to use Remote > Serial Console (as compared to using > the remote console or IRC), the Remote Serial Console allows telnet or > SSH users to interact with the > server remotely and without requiring an iLO 2 Advanced license and is > the only way a true text-based > remote console is presented by iLO 2. > " > > If I've understood correct, the "text console" mode from iLO 1 is > removed all together in favor for graphical mode (the internal > workings have been changed). Yes, ssh and serial works, I am using that. I would have preferred they kept the text console too. I often enough issues with the graphical (ActiveX and Java) on iLO2, that I end up using remote desktop or vnc into a local machine (local to the iLO) and run a browser from there. ssh text console on iLO1 is working for me from my crackberry ssh. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 21:35:06 2008 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 945E7106566B for ; Mon, 17 Mar 2008 21:35:06 +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 4665A8FC20 for ; Mon, 17 Mar 2008 21:35:06 +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 <0JXW0068O9A7E460@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 17 Mar 2008 22:34:55 +0100 (CET) Received: from kg-work.kg4.no ([80.202.173.59]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JXW00HRM9A6UG90@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 17 Mar 2008 22:34:55 +0100 (CET) Date: Mon, 17 Mar 2008 22:34:54 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080317223454.84af197c.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080317113752.GA44336@eos.sc1.parodius.com> References: <89A232E0-CB36-4EE0-B66D-DCA4AB6F20DD@stromnet.se> <47D85B27.1000006@osoft.us> <47D86A01.8070500@osoft.us> <20080316073616.GQ87650@evil.alameda.net> <7FA8F29C-8D96-49E7-A927-8482F0ADBED1@stromnet.se> <20080317085240.GA40391@eos.sc1.parodius.com> <7982C43A-4252-46EC-9FA1-5AE78CFD88B0@stromnet.se> <20080317113752.GA44336@eos.sc1.parodius.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd6.3) 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: HP ProLiant DL360 G5 success stories? 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, 17 Mar 2008 21:35:06 -0000 On Mon, 17 Mar 2008 04:37:52 -0700 Jeremy Chadwick wrote: > IPMI is one of those things that's presented as a great idea (and it > but the actual implementations done by vendors (or at least > Supermicro) appears to be a complete mess. Very disappointing. Perhpas we should have forced all x86 / x64 vendors to use Open Firmware instead of BIOS. Would have solved many problems over the years. Or maybe not. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 21:46:24 2008 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 F1EA41065670; Mon, 17 Mar 2008 21:46:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6388FC24; Mon, 17 Mar 2008 21:46:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id m2HLZbwh078329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 22:35:37 +0100 (CET) (envelope-from h.schmalzbauer@omnisec.de) Message-ID: <47DEE428.70300@omnisec.de> Date: Mon, 17 Mar 2008 22:35:36 +0100 From: Harald Schmalzbauer Organization: OmniSEC User-Agent: Thunderbird 2.0.0.12 (X11/20080308) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200803171033.m2HAXOeN055116@repoman.freebsd.org> <4033FB26-0458-4EAE-A43E-4AB17B78B37D@mac.com> In-Reply-To: <4033FB26-0458-4EAE-A43E-4AB17B78B37D@mac.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig082F95E64C04F2780164EE27" Cc: cvs-src@freebsd.org, Poul-Henning Kamp Subject: Re: cvs commit: src/sys/sys ata.h src/sbin/atacontrol atacontrol.8 atacontrol.c src/sys/dev/ata ata-all.c ata-all.h ata-disk.c ata-disk.h 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, 17 Mar 2008 21:46:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig082F95E64C04F2780164EE27 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Marcel Moolenaar wrote am 17.03.2008 17:28 (localtime): >=20 > On Mar 17, 2008, at 3:33 AM, Poul-Henning Kamp wrote: >=20 >> phk 2008-03-17 10:33:23 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/sys ata.h >> sbin/atacontrol atacontrol.8 atacontrol.c >> sys/dev/ata ata-all.c ata-all.h ata-disk.c ata-disk.h >> Log: >> Add a "spindown" facility to ata-disks: If no requests have been=20 >> received >> for a configurable number of seconds, spin the disk down. Spin it ba= ck >> up on the next request. >=20 > Nice! Very nice indeed, I've been hoping for this. Thanks Poul-Henning! For those who want to try it against -STABLE, you'll find the cumulated=20 diff at=20 http://www.schmalzbauer.de/downloads/atacontrol-spindown_RELENG7.diff Copy to /usr/src and 'patch -i atacontrol-spindown_RELENG7.diff' Best regards, -Harry --------------enig082F95E64C04F2780164EE27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkfe5CkACgkQLDqVQ9VXb8hxFgCgoJY1kAnZobtkgYvIf3qFHYTU HZgAoLa0rVhObD88kel0Jxj4M5koztov =wqtH -----END PGP SIGNATURE----- --------------enig082F95E64C04F2780164EE27-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 22:29:51 2008 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 24950106566B; Mon, 17 Mar 2008 22:29:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 2FEDB8FC20; Mon, 17 Mar 2008 22:29:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 235838216-1834499 for multiple; Mon, 17 Mar 2008 18:28:01 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m2HMTbv0081565; Mon, 17 Mar 2008 18:29:37 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alfred Perlstein Date: Mon, 17 Mar 2008 16:59:33 -0400 User-Agent: KMail/1.9.7 References: <20080315024114.GD67856@elvis.mu.org> <200803171127.20561.jhb@freebsd.org> <20080317201014.GA67856@elvis.mu.org> In-Reply-To: <20080317201014.GA67856@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171659.33547.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]); Mon, 17 Mar 2008 18:29:37 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6277/Mon Mar 17 14:08:59 2008 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: stable@freebsd.org, freebsd-smp@freebsd.org Subject: Re: timeout/untimeout race conditions/crash [patch] 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, 17 Mar 2008 22:29:51 -0000 On Monday 17 March 2008 04:10:14 pm Alfred Perlstein wrote: > * John Baldwin [080317 09:43] wrote: > > > > This is not a bug. Don't use untimeout(9) as it is not guaranteed to be > > reliable. Instead, use callout_*(). Your patch doesn't solve any races as > > the driver detach routine needs to use callout_drain() and not just > > callout_stop/untimeout anyways. Fix your broken drivers. > > I understand that some old Giant locked code can issue timeout/untimeout > without Giant held, which would certainly cause this issue to happen > and is uncorrectable, however, this is with completely Giant locked > code. > > We are not trying to use timeout(9) for mpsafe code, this is old > code and relies upon Giant. > > Giant locked code should be timeout/untimeout safe. As explained > in my email, there exists a condition where the Giant locked code > can have a timer fire even though proper Giant locking is observed. > > For a Giant locked subsystem, one should be able to have the following > code work: > > mtx_lock(&Giant); /* formerly spl higher than softclock */ > untimeout(&func, arg, &sc->handle); > free(sc); > mtx_unlock(&Giant); /* formerly splx() */ > > Normally splsoftclock would completely block the timeout from firing > and this sort of code would be safe. It is no longer safe due to > a BUG in the way that Giant is used. > > Please reread the original mail to better understand the synopsis > of the problem. Hmm. My worry is about leaving the callout structure around while invoking the timeout routine itself, but it is already off the callwheel so it shouldn't be visible via untimeout() to any other code. I guess the patch is ok, but I'll be happy when we can axe timeout/untimeout altogether. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 22:42:08 2008 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 B2E8F106566C for ; Mon, 17 Mar 2008 22:42:08 +0000 (UTC) (envelope-from SRS0=a410464dd65c0c447551906f028ffb90325b1994=643=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 156CD8FC24 for ; Mon, 17 Mar 2008 22:42:07 +0000 (UTC) (envelope-from SRS0=a410464dd65c0c447551906f028ffb90325b1994=643=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id XZH63206; Mon, 17 Mar 2008 15:42:06 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8B03A4500F; Mon, 17 Mar 2008 15:41:36 -0700 (PDT) To: Kurt Jaeger In-Reply-To: Your message of "Mon, 17 Mar 2008 07:36:23 BST." <20080317063623.GA3180@home.opsec.eu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205793696_74408P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2008 15:41:36 -0700 From: "Kevin Oberman" Message-Id: <20080317224136.8B03A4500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Kurt Jaeger X-To_Domain: c0mplx.org X-To: Kurt Jaeger X-To_Email: lists@c0mplx.org X-To_Alias: lists Cc: peter stern , freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 17 Mar 2008 22:42:08 -0000 --==_Exmh_1205793696_74408P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 17 Mar 2008 07:36:23 +0100 > From: Kurt Jaeger > Sender: owner-freebsd-stable@freebsd.org > > Hi! > > > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > > shipped with. I've been using FreeBSD since 2.2 and have never had much > > trouble with it until the 6 branch was released. My hardware is pretty > > generic Intel brand D865 motherboard, matrox g550 video. I don't customize > > the kernel. I do clean installs not upgrades. > > Basically, the problem is with the matrox board. > > Due to the very same reasons I had to upgrade my workstation > (good excuse 8-) > > Matrox provides a mga_hal binary to support the relevant resolution > and other gimmicks of that board. This binary works with xorg-6.x, > but not with xorg-7.x, because there were changes in the interfaces > to the low-level things. > > As far as I can see, there is no driver from mga for 7.x available > as of now. > > -- > pi@opsec.eu +49 171 3101372 12 years to go ! > _______________________________________________ > 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" > I have run the Matrox G550 under both 6 and 7. I had some problems, but not too many. I do need to use xrandr to set up the proper resolution, though. #!/bin/sh # Set 1280x1024 mode on second display xrandr --addmode VGA2 1280x1024 # Set 1024x768 mode on second port (Why? Why not.) xrandr --addmode VGA2 1024x768 # Set the second port to use 1280x1024 xrandr --output VGA2 --mode 1280x1024 If you have a dual-monitor setup, you need xf86-video-mga-1.9.100. The version in ports is mga-1.4.7. You will have to pull the old port out of cvs. The version was rolled back on Jan. 2, 2008 due to problems people were having with the new code, Let me know if you need a copy of my xorg.conf for this beast. The xrandr setup is a bit different from the old one. -- 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 --==_Exmh_1205793696_74408P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH3vOgkn3rs5h7N1ERAnogAJwNGaVb9Pim36Q0D/Tv4ZjaJnoAZwCfS6w+ /J0noUfophOJHma659BbRWE= =UmUm -----END PGP SIGNATURE----- --==_Exmh_1205793696_74408P-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 17 23:32:47 2008 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 E62C7106566B for ; Mon, 17 Mar 2008 23:32:47 +0000 (UTC) (envelope-from snoonan@snoonan.com) Received: from proxy1.addr.com (proxy1.addr.com [38.113.244.28]) by mx1.freebsd.org (Postfix) with ESMTP id C9E048FC17 for ; Mon, 17 Mar 2008 23:32:47 +0000 (UTC) (envelope-from snoonan@snoonan.com) Received: from [127.0.0.1] (san-static-216.70.149.16.mpowercom.net [216.70.149.16]) by proxy1.addr.com (8.12.11/8.12.8/Submit) with ESMTP id m2HNHaJa004545; Mon, 17 Mar 2008 16:17:40 -0700 (PDT) Message-ID: <47DEFC05.5060801@snoonan.com> Date: Mon, 17 Mar 2008 16:17:25 -0700 From: Sean Noonan User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: makeworld broken on 7 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, 17 Mar 2008 23:32:48 -0000 Hi, Just put together a new box and installed 7-RELEASE on it. Cvsup'd RELENG_7 branch and tried makeworld. It keeps blowing up at the same spot: ln -fs libobjc.so.3 /usr/obj/usr/src/tmp/usr/lib/libobjc.so ===> gnu/lib/libssp (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libssp.a /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libssp.so.0 /usr/obj/usr/src/tmp/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 ssp.h /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/string.h /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/stdio.h /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/unistd.h /usr/obj/usr/src/tmp/usr/include/ssp ln -fs /usr/obj/usr/src/tmp/lib/libssp.so.0 /usr/obj/usr/src/tmp/usr/lib/libssp.so ===> gnu/lib/libssp/libssp_nonshared (install) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libssp_nonshared.a /usr/obj/usr/src/tmp/usr/lib 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error nothing# Does anyone have any suggestions on how to get past this? TIA, --Sean Noonan From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 00:18:27 2008 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 3B1C5106566C for ; Tue, 18 Mar 2008 00:18:27 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3DC8FC14 for ; Tue, 18 Mar 2008 00:18:27 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0EED81CC060; Mon, 17 Mar 2008 17:18:27 -0700 (PDT) Date: Mon, 17 Mar 2008 17:18:27 -0700 From: Jeremy Chadwick To: Sean Noonan Message-ID: <20080318001827.GA63552@eos.sc1.parodius.com> References: <47DEFC05.5060801@snoonan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DEFC05.5060801@snoonan.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: stable@freebsd.org Subject: Re: makeworld broken on 7 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: Tue, 18 Mar 2008 00:18:27 -0000 On Mon, Mar 17, 2008 at 04:17:25PM -0700, Sean Noonan wrote: > Hi, > > Just put together a new box and installed 7-RELEASE on it. Cvsup'd > RELENG_7 branch and tried makeworld. It keeps blowing up at the same spot: Are you building world with any -j flags? > ln -fs libobjc.so.3 /usr/obj/usr/src/tmp/usr/lib/libobjc.so > ===> gnu/lib/libssp (install) > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libssp.a > /usr/obj/usr/src/tmp/usr/lib > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libssp.so.0 > /usr/obj/usr/src/tmp/lib > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 ssp.h > /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/string.h > /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/stdio.h > /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp/unistd.h > /usr/obj/usr/src/tmp/usr/include/ssp > ln -fs /usr/obj/usr/src/tmp/lib/libssp.so.0 > /usr/obj/usr/src/tmp/usr/lib/libssp.so > ===> gnu/lib/libssp/libssp_nonshared (install) > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 > libssp_nonshared.a /usr/obj/usr/src/tmp/usr/lib > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > nothing# The last few lines don't appear to be what's erroring. If you're using -j, the error is actually somewhere further up/hidden. Try rebuilding world without -j, this should give some more clues. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 01:34:31 2008 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 6F0921065722 for ; Tue, 18 Mar 2008 01:34:31 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from d4407.kankyo-u.ac.jp (unknown [IPv6:2001:3e0:a84:2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCAFA8FC26 for ; Tue, 18 Mar 2008 01:34:30 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from roddy.4407.kankyo-u.ac.jp.kankyo-u.ac.jp (localhost [IPv6:::1]) by d4407.kankyo-u.ac.jp (8.14.2/8.14.2) with ESMTP id m2I1YNSJ050581 for ; Tue, 18 Mar 2008 10:34:23 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) Sender: nakaji@kankyo-u.ac.jp From: NAKAJI Hiroyuki To: freebsd-stable@freebsd.org References: Date: Tue, 18 Mar 2008 10:34:22 +0900 In-Reply-To: (Pete French's message of "Mon, 17 Mar 2008 11:38:24 +0000") Message-ID: <87abkw24td.fsf@roddy.4407.kankyo-u.ac.jp> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 01:34:31 -0000 >>>>> In >>>>> Pete French wrote: > > G550's are very old cards, I don't think it's unreasonable to expect > > that someone doing RC testing would have one installed. > I missed the original posting, but I had a G550 (I think - may have > been a 450, but I am fairly sure it was a 550) in my workstation here > until a couple of weeks ago, and it ran fine under 6.3 and 7.0. The only > slight niggle we had was having to disable the hardware mouse cursor as > otherwise there was no pointerr - but this is well documented as a problem > if you google for it. My G550 is fine with xorg 7.3 and FreeBSD/i386 8.0-CURRENT. The installation informations are available at http://home.jp.freebsd.org/~nakaji/g550/ BTW, I think freebsd-x11 is better place. -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 03:31:18 2008 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 5ADCD106564A for ; Tue, 18 Mar 2008 03:31:18 +0000 (UTC) (envelope-from betts@norden1.com) Received: from picard.norden1.com (adsl-76-215-134-130.dsl.toldoh.sbcglobal.net [76.215.134.130]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABF48FC13 for ; Tue, 18 Mar 2008 03:31:17 +0000 (UTC) (envelope-from betts@norden1.com) Received: from localhost (localhost [127.0.0.1]) by picard.norden1.com (Postfix) with ESMTP id A62D31CD50 for ; Mon, 17 Mar 2008 23:11:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at norden1.com Received: from picard.norden1.com ([127.0.0.1]) by localhost (picard.norden1.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgwJTI63exI4 for ; Mon, 17 Mar 2008 23:11:14 -0400 (EDT) Received: from [192.168.2.114] (adsl-76-215-134-134.dsl.toldoh.sbcglobal.net [76.215.134.134]) by picard.norden1.com (Postfix) with ESMTP id DC7FB1CD09 for ; Mon, 17 Mar 2008 23:11:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v753) To: freebsd-stable@freebsd.org Message-Id: From: Darrell Betts Date: Mon, 17 Mar 2008 23:11:12 -0400 X-Mailer: Apple Mail (2.753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Error I receive after upgrading from 6.2 to 6.3 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, 18 Mar 2008 03:31:18 -0000 I upgraded 6.2 to 6.3 following the instructions on this page http:// www.cyberciti.biz/faq/upgrade-freebsd-server-software/ Everything went well until I tired portversion -l "<" and I received this error: /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:119:in `fill': MOVED file format error (PortsDB::MOVEDError) from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in `each' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in `fill' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in `open' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in `fill' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:107:in `initialize' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in `new' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in `setup' from /usr/local/lib/ruby/site_ruby/1.8/pkgtools.rb:256:in `init_pkgtools_global' from /usr/local/sbin/portversion:175:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' from /usr/local/sbin/portversion:80:in `new' from /usr/local/sbin/portversion:80:in `main' from /usr/local/sbin/portversion:364 I have tried pkgdb -Uu and receive the error: MOVED file format error I would like to upgrade to 7.0 but I need to get this fixed first. What can I do? Thanks Darrell ----------------------------------------------------------- Looks like I Picked the Wrong Week to Stop Sniffing Glue. -- Steve McCroskey -- Live ATC Feed from Toledo Express Airport http://audio.liveatc.net: 8012/ktol.m3u From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 04:19:19 2008 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 88CB11065675 for ; Tue, 18 Mar 2008 04:19:19 +0000 (UTC) (envelope-from ge@weijers.org) Received: from fed1rmpop112.cox.net (fed1rmpop112.cox.net [68.230.241.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3288FC14 for ; Tue, 18 Mar 2008 04:19:03 +0000 (UTC) (envelope-from ge@weijers.org) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080318035209.GHSQ17042.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Mon, 17 Mar 2008 23:52:09 -0400 Received: from [192.168.20.41] ([72.193.251.70]) by fed1rmimpo03.cox.net with bizsmtp id 2TrR1Z0011XtSiG0000000; Mon, 17 Mar 2008 23:51:25 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?G=E9_Weijers?= Date: Mon, 17 Mar 2008 20:49:53 -0700 To: Darrell Betts X-Mailer: Apple Mail (2.753) Cc: freebsd-stable@freebsd.org Subject: Re: Error I receive after upgrading from 6.2 to 6.3 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, 18 Mar 2008 04:19:19 -0000 The last line in /usr/ports/MOVED is wrong, there's a field missing. =20 Replacing the first "|" with "||" seems to fix it. G=E9 On Mar 17, 2008, at 8:11 PM, Darrell Betts wrote: > I upgraded 6.2 to 6.3 following the instructions on this page =20 > http://www.cyberciti.biz/faq/upgrade-freebsd-server-software/ > > Everything went well until I tired portversion -l "<" and I =20 > received this error: > /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:119:in `fill': MOVED =20 > file format error (PortsDB::MOVEDError) > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in =20 > `each' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in =20 > `fill' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in =20 > `open' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in =20 > `fill' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:107:in =20 > `initialize' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in `new' > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in =20 > `setup' > from /usr/local/lib/ruby/site_ruby/1.8/pkgtools.rb:256:in =20 > `init_pkgtools_global' > from /usr/local/sbin/portversion:175:in `main' > from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' > from /usr/local/sbin/portversion:80:in `new' > from /usr/local/sbin/portversion:80:in `main' > from /usr/local/sbin/portversion:364 > > I have tried pkgdb -Uu and receive the error: > MOVED file format error > > I would like to upgrade to 7.0 but I need to get this fixed first. =20 > What can I do? > > Thanks > Darrell > > ----------------------------------------------------------- > Looks like I Picked the Wrong Week to Stop Sniffing Glue. > -- Steve McCroskey -- > > Live ATC Feed from Toledo Express Airport http://audio.liveatc.net:=20 > 8012/ktol.m3u > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-=20 > unsubscribe@freebsd.org" -- G=E9 Weijers ge@weijers.org From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 04:45:52 2008 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 34D6F1065670 for ; Tue, 18 Mar 2008 04:45:52 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (209-193-47-81-cdsl-rb1.fai.acsalaska.net [209.193.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id A0F738FC1D for ; Tue, 18 Mar 2008 04:45:51 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (localhost.65north.com [127.0.0.1]) by jago.65north.com (8.13.3/8.13.3) with ESMTP id m2I4jnf2003291; Mon, 17 Mar 2008 20:45:49 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Received: from localhost (pstern@localhost) by jago.65north.com (8.13.3/8.13.3/Submit) with ESMTP id m2I4jmnA003288; Mon, 17 Mar 2008 20:45:49 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Date: Mon, 17 Mar 2008 20:45:48 -0800 (AKDT) From: peter stern To: Brad Pitney In-Reply-To: <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> Message-ID: <20080317203212.M3271@jago.65north.com> References: <20080316211253.M2398@jago.65north.com> <3dd203290803162338k3b277790kec608ccfc7e59082@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 04:45:52 -0000 On Mon, 17 Mar 2008, Brad Pitney wrote: > On Mon, Mar 17, 2008 at 5:29 AM, peter stern wrote: >> I'd appreciate suggestions on how to get a working xorg from the mess 6.3 >> shipped with. I've been using FreeBSD since 2.2 and have never had much >> trouble with it until the 6 branch was released. My hardware is pretty >> generic Intel brand D865 motherboard, matrox g550 video. I don't customize >> the kernel. I do clean installs not upgrades. >> > > have you tried without an xorg.conf? > >> The xorg in 6.3 doesn't install much in the way of required drivers. I got >> the mouse and keyboard drivers installed and also the mga driver. I have >> run xorgconfig to create what seems like a working xorg.conf. Startx >> brings up twm but only in 640x480. I cannot change modes. And yes, I have >> mode lines defined. If I put the correct horizontal and vertical scan >> rates in for my Viewsonic PT810 monitor, I get a screen display with lines >> precessing through it. xdm gives the same result. >> >> I have tried the other suggestions on configuring X in the FreeBSD >> handbook, including creating a basic xorg.conf. It tests okay but only in >> 640x480 and it has no modelines in the .conf. Adding modelines doesn't fix >> the problem. >> > > I suspect modelines won't help and there might be a bug in xf86-video-mga? > >> The initial install was done by sysinstall under the predefined >> xdeveloper selection. I tried reinstalling xorg from ports by running make >> deinstall and make reinstall but with no change in behavior. >> > > what about installing just base then using an up-to-date ports? > >> My hardware has no problems running Slackware 12 or Openbsd 4.2. Under >> those OSs, X11 works fine and configures without problems. >> >> What has happened to quality control in the FreeBSD release? > > is it really a FreeBSD issue? > >> >> peter >> I tried firing x up without an xorg. I get a 640x480 screen that appears otherwise normal with no precessing. No other modes are available. I took the drive and put it in a computer with an nvidia GX400, pointed the xorg.conf to the nv driver. X started up without a problem. It does appear the problem is with the FreeBSD mga driver. I have a G550 with vga and dvi outputs but I am only using the vga output. The quality control issue I mentioned has to do with why the default install for x-developer did not install the device drivers for input-keyboard and input-mouse. That would seem to be a pretty basic problem and should have been caught by quality control. If you look at the x devices directory, very little is in there. I had to manually add the mouse and keyboard devices, from packages, to get x to even start up. What is the trick for determining the driver version? When I try to compare the Xorg.0.log from OpenBSD 4.2, Slackware 12 and FreeBSD 6.3, the mga and xorg versions differ completely. The x.org site is not much help on the mga driver version issue either. The mga man page references the mga_hal binary available from matrox however the only reference I could find on that site for it dates back to 2001 and there is no info on how to use it. It is not clear it is needed for just basic output from a G550. Getting x running should not be this hard. Thanks, peter From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 04:52:53 2008 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 6754E1065673 for ; Tue, 18 Mar 2008 04:52:53 +0000 (UTC) (envelope-from lippemail@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.241]) by mx1.freebsd.org (Postfix) with ESMTP id 0558A8FC27 for ; Tue, 18 Mar 2008 04:52:52 +0000 (UTC) (envelope-from lippemail@gmail.com) Received: by hs-out-0708.google.com with SMTP id m63so4769533hsc.11 for ; Mon, 17 Mar 2008 21:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:reply-to:x-mailer:mime-version:content-type:sender; bh=V/xBmhPQTXxhmGq9dSGyMIwj0SDjUfBWgssGn2ouGJk=; b=u02Wdby8HtS8DuYqKBcOvr4/WPMrKvZZdsyj2Lh+Ydc8Zd16hyDeFi5iL5CPt9PF1rbBMu0j1hfAWZBsvdU9GaAwOJpYPTT0B7rPvYNGL1IAlMvlUpTkE7r6q4GrGko7dLBtz5gyax7Z25ASEbXAde81Ad4MU3yrwY0cxo5EQzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:reply-to:x-mailer:mime-version:content-type:sender; b=Vrt/yx8JyQ3ILpDIfN3UJrDD28lMSerbRrdzZLgm3hdL7MpnGqE4Rt6gJbx3HN3r2EsC4UMxljDY51ymgfyOOw7qjKK9PUFf2Zqui6njJpIxoKVwkhTH4uFvWWKNoHJMyEA7K8B8aN5Y9I6y8fozPYve8KqXBMNCnDNdFBrfK7I= Received: by 10.101.67.15 with SMTP id u15mr582131ank.108.1205814245835; Mon, 17 Mar 2008 21:24:05 -0700 (PDT) Received: from shire.freebsd.org.freebsd.org ( [189.71.157.106]) by mx.google.com with ESMTPS id 39sm30586040agb.16.2008.03.17.21.24.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Mar 2008 21:24:05 -0700 (PDT) Date: Tue, 18 Mar 2008 01:23:48 -0300 From: Felippe de Meirelles Motta To: freebsd-stable@freebsd.org Message-ID: <20080318012348.3dfa5f6c@shire.freebsd.org.freebsd.org> In-Reply-To: References: X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/thasxTZlE=kcOGwsbjIHugn"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Sender: Felippe de Meirelles Motta Subject: Re: Error I receive after upgrading from 6.2 to 6.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lippe@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 04:52:53 -0000 --Sig_/thasxTZlE=kcOGwsbjIHugn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Em Mon, 17 Mar 2008 20:49:53 -0700 G=C3=A9 Weijers escreveu: > The last line in /usr/ports/MOVED is wrong, there's a field missing. =20 > Replacing the first "|" with "||" seems to fix it. >=20 > G=C3=A9 >=20 >=20 > On Mar 17, 2008, at 8:11 PM, Darrell Betts wrote: >=20 > > I upgraded 6.2 to 6.3 following the instructions on this page =20 > > http://www.cyberciti.biz/faq/upgrade-freebsd-server-software/ > > > > Everything went well until I tired portversion -l "<" and I =20 > > received this error: > > /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:119:in `fill': MOVED =20 > > file format error (PortsDB::MOVEDError) > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in =20 > > `each' > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:113:in =20 > > `fill' > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in =20 > > `open' > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:112:in =20 > > `fill' > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:107:in =20 > > `initialize' > > from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in > > `new' from /usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:182:in =20 > > `setup' > > from /usr/local/lib/ruby/site_ruby/1.8/pkgtools.rb:256:in =20 > > `init_pkgtools_global' > > from /usr/local/sbin/portversion:175:in `main' > > from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' > > from /usr/local/sbin/portversion:80:in `new' > > from /usr/local/sbin/portversion:80:in `main' > > from /usr/local/sbin/portversion:364 > > > > I have tried pkgdb -Uu and receive the error: > > MOVED file format error > > > > I would like to upgrade to 7.0 but I need to get this fixed first. =20 > > What can I do? > > > > Thanks > > Darrell > > > > ----------------------------------------------------------- > > Looks like I Picked the Wrong Week to Stop Sniffing Glue. > > -- Steve McCroskey -- > > > > Live ATC Feed from Toledo Express Airport http://audio.liveatc.net:=20 > > 8012/ktol.m3u > > > > > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-=20 > > unsubscribe@freebsd.org" >=20 > -- > G=C3=A9 Weijers > ge@weijers.org >=20 >=20 >=20 > _______________________________________________ > 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" Hi G=C3=A9, It was fixed! Thanks! --=20 lippe@FreeBSD.org Felippe de Meirelles Motta --Sig_/thasxTZlE=kcOGwsbjIHugn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkffQ9QACgkQEv+IlQvbYkodzQCcDenPTYyEabxwnjXXt+771x4U WIIAn3wPtix4RwYrWkj1N0ccylSErMeV =rVUz -----END PGP SIGNATURE----- --Sig_/thasxTZlE=kcOGwsbjIHugn-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 05:24:47 2008 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 CDC64106564A for ; Tue, 18 Mar 2008 05:24:47 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (209-193-47-81-cdsl-rb1.fai.acsalaska.net [209.193.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id 2579E8FC25 for ; Tue, 18 Mar 2008 05:24:46 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (localhost.65north.com [127.0.0.1]) by jago.65north.com (8.13.3/8.13.3) with ESMTP id m2I5NBei003354; Mon, 17 Mar 2008 21:23:12 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Received: from localhost (pstern@localhost) by jago.65north.com (8.13.3/8.13.3/Submit) with ESMTP id m2I5N96J003351; Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Date: Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) From: peter stern To: Kevin Oberman In-Reply-To: <20080317224136.8B03A4500F@ptavv.es.net> Message-ID: <20080317211824.H3271@jago.65north.com> References: <20080317224136.8B03A4500F@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kurt Jaeger , freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 05:24:47 -0000 On Mon, 17 Mar 2008, Kevin Oberman wrote: >> Date: Mon, 17 Mar 2008 07:36:23 +0100 >> From: Kurt Jaeger >> Sender: owner-freebsd-stable@freebsd.org >> >> Hi! >> >>> I'd appreciate suggestions on how to get a working xorg from the mess 6.3 >>> shipped with. I've been using FreeBSD since 2.2 and have never had much >>> trouble with it until the 6 branch was released. My hardware is pretty >>> generic Intel brand D865 motherboard, matrox g550 video. I don't customize >>> the kernel. I do clean installs not upgrades. >> >> Basically, the problem is with the matrox board. >> >> Due to the very same reasons I had to upgrade my workstation >> (good excuse 8-) >> >> Matrox provides a mga_hal binary to support the relevant resolution >> and other gimmicks of that board. This binary works with xorg-6.x, >> but not with xorg-7.x, because there were changes in the interfaces >> to the low-level things. >> >> As far as I can see, there is no driver from mga for 7.x available >> as of now. >> >> -- >> pi@opsec.eu +49 171 3101372 12 years to go ! >> _______________________________________________ >> 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" >> > > I have run the Matrox G550 under both 6 and 7. I had some problems, but > not too many. I do need to use xrandr to set up the proper resolution, > though. > > #!/bin/sh > # Set 1280x1024 mode on second display > xrandr --addmode VGA2 1280x1024 > # Set 1024x768 mode on second port (Why? Why not.) > xrandr --addmode VGA2 1024x768 > # Set the second port to use 1280x1024 > xrandr --output VGA2 --mode 1280x1024 > > If you have a dual-monitor setup, you need xf86-video-mga-1.9.100. The > version in ports is mga-1.4.7. You will have to pull the old port out of > cvs. The version was rolled back on Jan. 2, 2008 due to problems people > were having with the new code, > > Let me know if you need a copy of my xorg.conf for this beast. The > xrandr setup is a bit different from the old one. > -- > 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 > I was not familiar with using xrandr. I am now able to control the resolution and refresh rate from the command line. xrandr -v however is not reporting all the refresh rates that this monitor is capable of at higher resolutions. Am I going to have to set those manually? This is an ugly way to have to deal with X. So this definitely means the mga driver is broken? I would appreciate a copy of your xorg.conf Thanks for your suggestions. peter From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 05:53:20 2008 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 6029F106566C for ; Tue, 18 Mar 2008 05:53:20 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (unknown [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 07F1F8FC14 for ; Tue, 18 Mar 2008 05:53:20 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbUlD-000C8i-1z for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 06:53:19 +0100 Date: Tue, 18 Mar 2008 06:53:19 +0100 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20080318055319.GC3180@home.opsec.eu> References: <20080317063623.GA3180@home.opsec.eu> <20080317224136.8B03A4500F@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080317224136.8B03A4500F@ptavv.es.net> Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 05:53:20 -0000 Hi! > > > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > > > shipped with. [...] > > Basically, the problem is with the matrox board. > I have run the Matrox G550 under both 6 and 7. I had some problems, but > not too many. I do need to use xrandr to set up the proper resolution, > though. > > #!/bin/sh > # Set 1280x1024 mode on second display > xrandr --addmode VGA2 1280x1024 > # Set 1024x768 mode on second port (Why? Why not.) > xrandr --addmode VGA2 1024x768 > # Set the second port to use 1280x1024 > xrandr --output VGA2 --mode 1280x1024 Try to run 1600x1200 dual-headed, I failed to get *that* to work. It worked with the old xorg-6.x. > If you have a dual-monitor setup, you need xf86-video-mga-1.9.100. The > version in ports is mga-1.4.7. You will have to pull the old port out of > cvs. The version was rolled back on Jan. 2, 2008 due to problems people > were having with the new code, While this probably works (I experimented with that but failed to get 1600x1200 dual-head), it looks like a difficult thing to maintain in the future. I think matrox should provide a working hal for 7.3 8-) > Let me know if you need a copy of my xorg.conf for this beast. The > xrandr setup is a bit different from the old one. Providing that would be definitly a good service. I still have the old hardware ready to upgrade, too 8-) -- pi@opsec.eu +49 171 3101372 12 years to go ! From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 09:14:40 2008 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 B3DA11065672 for ; Tue, 18 Mar 2008 09:14:40 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB0C8FC3A for ; Tue, 18 Mar 2008 09:14:40 +0000 (UTC) (envelope-from valerio.daelli@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so6400561wxd.7 for ; Tue, 18 Mar 2008 02:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/Ke8lf08qt9mC4wJAftvw9hjHyRszEKEd6pk+mNVRxA=; b=H4MBVwrDewifZqe4okPgKPOWZ63elcmDwuCZA+mWLmhPlyR9Y46aJZd5QcMi8LeqT2S3+01AV5tGhmjs3Vs8u37461T6I3fu9e2E4Vio6+IT0cWdeWbw1hxOYhMhoVDVYb83LDom8UUZsIvBVPOqHfFZh9DEM1KnPGtu6mkJTqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NbQOsh7pZYIpbOnThLggOegrCM9R5jIbfkDsgj658+hQBiXPi49Xvnry0qZFe01EodhdGmHAFOUHpgnNaSQlc73Hn/Papj8uu+jVpkJneYWuI5JyMVetasPqaERxXQ0BlFr0X1DehgMIMtUBnWn4DIpdEvdgf0A/5RnQlJ83ut8= Received: by 10.114.132.5 with SMTP id f5mr1064563wad.50.1205830136140; Tue, 18 Mar 2008 01:48:56 -0700 (PDT) Received: by 10.114.113.14 with HTTP; Tue, 18 Mar 2008 01:48:56 -0700 (PDT) Message-ID: <27dbfc8c0803180148q3aa8323ev8a06a25eef46257f@mail.gmail.com> Date: Tue, 18 Mar 2008 09:48:56 +0100 From: "Valerio Daelli" To: "Daniel Bond" , freebsd-stable@freebsd.org In-Reply-To: <47DE9638.6080609@danielbond.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47DE9638.6080609@danielbond.org> Cc: Subject: Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 18 Mar 2008 09:14:40 -0000 On Mon, Mar 17, 2008 at 5:03 PM, Daniel Bond wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > Now, if I uncomment the line with pam_mkhomedir.so on it, logins stop to > work. In /var/log/auth.log I now see two lines appearing: > > Mar 17 16:46:40 webmail sshd[98923]: nss_ldap: could not search LDAP > server - Server is unavailable > Mar 17 16:46:40 webmail sshd[98923]: error: PAM: pam_open_session(): > error in service module Hi not sure if this may solve your problem. We found a similar problem on FreeBSD 7.0 with pam_mkhomedir.so and sshd. We solved using pam_exec.so and a custom shell script to create the home directories. Hope this help Valerio Daelli From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 10:05:06 2008 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 5B7EA106566C for ; Tue, 18 Mar 2008 10:05:06 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailtwo.nsn.no [62.89.38.161]) by mx1.freebsd.org (Postfix) with SMTP id B233F8FC1F for ; Tue, 18 Mar 2008 10:05:05 +0000 (UTC) (envelope-from db@danielbond.org) Received: (qmail 53786 invoked by uid 0); 18 Mar 2008 10:05:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (85.95.44.187) by mail.nsn.no with SMTP; 18 Mar 2008 10:05:03 -0000 Message-ID: <47DF93CE.9050406@danielbond.org> Date: Tue, 18 Mar 2008 11:05:02 +0100 From: Daniel Bond User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Valerio Daelli References: <47DE9638.6080609@danielbond.org> <27dbfc8c0803180148q3aa8323ev8a06a25eef46257f@mail.gmail.com> In-Reply-To: <27dbfc8c0803180148q3aa8323ev8a06a25eef46257f@mail.gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=1A8DD04A; url=http://web.danielbond.org/pgp/danielbond-pubkey.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 18 Mar 2008 10:05:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valerio Daelli wrote: | On Mon, Mar 17, 2008 at 5:03 PM, Daniel Bond wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Hi, |> Now, if I uncomment the line with pam_mkhomedir.so on it, logins stop to |> work. In /var/log/auth.log I now see two lines appearing: |> |> Mar 17 16:46:40 webmail sshd[98923]: nss_ldap: could not search LDAP |> server - Server is unavailable |> Mar 17 16:46:40 webmail sshd[98923]: error: PAM: pam_open_session(): |> error in service module | | Hi | not sure if this may solve your problem. We found a similar problem | on FreeBSD 7.0 with pam_mkhomedir.so and sshd. We solved using pam_exec.so | and a custom shell script to create the home directories. | Hope this help | | Valerio Daelli | _______________________________________________ | 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" Hi, thanks for the quick reply. This is a workaround that addresses the issue of users homedir not existing upon login-time, but there seems to be a serious problem in the underlying pam_ldap/nss_ldap modules somewhere. I've noticed after posting the previous post that ssh-pubkey/ssh-password authentication no longer works with PAM/ldap-setups, which I need for our external developers. I *really* want to find the underlying issue in this case, and resolve it. I have got some days off in the easter where I will look deeper into it, hoping to find an underlying issue, and create a patch. My only concern is not being able to find the bug, so I'm very happy for any suggestions on how to track this down, or any suspicions to what could be causing the problem. Cheers and happy Easter, Daniel Bond. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH35POUR3pKhqN0EoRApSkAJ9ywSzttH+VJTRrVQLtRvIXcwvyJgCeKkcO BuqV2YXaP+u8ve4tbyfInj8= =YMBU -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 10:18:44 2008 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 5006B1065677 for ; Tue, 18 Mar 2008 10:18:44 +0000 (UTC) (envelope-from dimma@higis.ru) Received: from mail.higis.ru (mail.higis.ru [213.147.37.35]) by mx1.freebsd.org (Postfix) with ESMTP id 071FE8FC23 for ; Tue, 18 Mar 2008 10:18:43 +0000 (UTC) (envelope-from dimma@higis.ru) Received: from [87.242.97.68] (port=58127 helo=dimma.masterhost.ru) by mail.higis.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbYNE-000AqT-Qu for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 12:44:48 +0300 Message-ID: <47DF8F10.8080200@higis.ru> Date: Tue, 18 Mar 2008 12:44:48 +0300 From: Dmitriy Kirhlarov User-Agent: Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <47DE9638.6080609@danielbond.org> In-Reply-To: <47DE9638.6080609@danielbond.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 18 Mar 2008 10:18:44 -0000 Hi! Daniel Bond wrote: > # auth ... This pam.d/ssh config working fine for me: # auth auth required pam_nologin.so no_warn auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass # account account required pam_nologin.so #account required pam_krb5.so account required pam_login_access.so account required /usr/local/lib/pam_ldap.so ignore_authinfo_unavail ignore_unknown_user account required pam_unix.so # session #session optional pam_ssh.so session required /usr/local/lib/pam_mkhomedir.so debug umask=0077 skel=/usr/local/share/skel session required pam_permit.so # password #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass > I'm pretty sure my ldap.conf and nsswitch.conf are OK, but here they are > anyway: > > > /usr/local/etc/nss_ldap.conf -> openldap/ldap.conf > /usr/local/etc/ldap.conf -> openldap/ldap.conf I'm not sure is it correct. etc/ldap.conf and etc/openldap/ldap.conf -- different files for different purposes. etc/nss_ldap.conf -> etc/ldap.conf -- it's correct. > # LDAP Defaults > # > > # See ldap.conf(5) for details > # This file should be world readable but not world writable. > > base dc=nsn, dc=no > HOST 1.slave.1881.int.nsn.no master.1881.int.nsn.no > > port 389 > ldap_version 3 > bind_policy soft ^^^^^^^^^^^^^^^^^^ Try replace to bind_policy hard Developers doesn't like "soft". I don't know why, but it periodically it's broken in new versions nss_ldap (2 time for last 3 years AFAIR). I'm not sure about current status. It must be tested. Also try echo "debug 9" >> /usr/local/etc/ldap.conf For details see slapd.conf(5) about loglevel WBR. Dmitriy From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 14:22:40 2008 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 B50981065676 for ; Tue, 18 Mar 2008 14:22:40 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id CA5408FC19 for ; Tue, 18 Mar 2008 14:22:39 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id YRO72036; Tue, 18 Mar 2008 07:22:36 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 989DE45014; Tue, 18 Mar 2008 07:22:35 -0700 (PDT) To: peter stern In-Reply-To: Your message of "Mon, 17 Mar 2008 21:23:09 -0800." <20080317211824.H3271@jago.65north.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205850155_31213P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 18 Mar 2008 07:22:35 -0700 From: "Kevin Oberman" Message-Id: <20080318142235.989DE45014@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: peter stern X-To_Domain: 65north.com X-To: peter stern X-To_Email: pstern@65north.com X-To_Alias: pstern Cc: Kurt Jaeger , freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 14:22:40 -0000 --==_Exmh_1205850155_31213P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) > From: peter stern > > > This is an ugly way to have to deal with X. So this definitely means the > mga driver is broken? > > I would appreciate a copy of your xorg.conf > > Thanks for your suggestions. > > peter Peter, Here is the config file from my G550 dual-head system. I won't promise that it is "correct". In fact, I suspect it is not, but it works for me. Section "ServerLayout" Identifier "xrandr" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/local/share/X11/rgb" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/bitstream-vera/" FontPath "/usr/local/lib/X11/fonts/URW/" FontPath "/usr/local/lib/X11/fonts/urwfonts-ttf/" EndSection Section "DRI" Mode 0666 EndSection Section "Extensions" Option "Composite" "Disable" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbOptions" "ctrl:swapcaps" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" #DisplaySize 370 300 # mm Identifier "Monitor0" VendorName "DEL" ModelName "DELL 1701FP" ### Comment all HorizSync and VertSync values to use DDC: # HorizSync 24.0 - 80.0 # VertRefresh 56.0 - 75.0 Option "DPMS" Option "Position" "0 0" EndSection Section "Monitor" Identifier "Monitor1" VendorName "DEL" ModelName "DELL 1701FP" HorizSync 24.0 - 36.0 VertRefresh 56.0 - 75.0 Option "DPMS" Option "Position" "1280 0" EndSection Section "Device" Identifier "Card0" Driver "mga" VendorName "Matrox Graphics, Inc." BoardName "MGA G400/G450" BusID "PCI:1:0:0" Option "HWcursor" "off" Option "AGPMode" "4" Option "Monitor-VGA1" "Monitor0" Option "Monitor-VGA2" "Monitor1" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Virtual 2560 1024 EndSubSection EndSection -- 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 --==_Exmh_1205850155_31213P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH39Arkn3rs5h7N1ERAklgAKCJYwu/Cg6DINJUGOcXqLmj3FDmUQCeOGne aiCPq2EeYRKUgYCHWRdCo7g= =FUjF -----END PGP SIGNATURE----- --==_Exmh_1205850155_31213P-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 14:25:04 2008 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 8AD76106566C for ; Tue, 18 Mar 2008 14:25:04 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id 702178FC14 for ; Tue, 18 Mar 2008 14:25:04 +0000 (UTC) (envelope-from vivek@khera.org) Received: from host-121.int.kcilink.com (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id CEAEF8A03A for ; Tue, 18 Mar 2008 10:25:03 -0400 (EDT) Message-Id: From: Vivek Khera To: FreeBSD Stable In-Reply-To: <20080317200532.GA942@trimind.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 10:25:03 -0400 References: <20080317200532.GA942@trimind.de> X-Mailer: Apple Mail (2.919.2) Subject: Re: hifn(4) causing system lockup 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, 18 Mar 2008 14:25:04 -0000 On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: > I've recently upgraded my 6.2-STABLE workstation to RELENG_7, > and I'm now experiencing system lockups that seem to be caused > by the hifn(4) driver. > > I've got a Soekris vpn1401 card to help with GELI disk en- > cryption. Reading from a GELI volume is causing the system to > freeze completely, which does not happen if software crypto is > used (i.e. hifn.ko not loaded). I can't enter kernel debugger > (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu > isn't up to par anyway. I've had the exact same kind of issue with the vpn1401 PCI card in a Dell box for my firewall running pfSense (at the tie it was based on FreeBSD 6.1 I believe). It would lock up the firewall within 2 hours to 4 days of uptime. Once we removed the card, no lockups. Soekris never responded to my questions about such behavior. In contrast, their mini-PCI cards I have installed on some WRAP boards never lockup using the same software. I blame the card. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 15:29:16 2008 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 01F60106566C for ; Tue, 18 Mar 2008 15:29:16 +0000 (UTC) (envelope-from rabe@uugrn.org) Received: from mail.uugrn.org (mail.uugrn.org [195.49.138.123]) by mx1.freebsd.org (Postfix) with ESMTP id 76F688FC2C for ; Tue, 18 Mar 2008 15:29:15 +0000 (UTC) (envelope-from rabe@uugrn.org) Received: from rabe.uugrn.org (root@rabe.uugrn.org [195.49.138.102]) by mail.uugrn.org (8.13.8/8.13.8) with ESMTP id m2IF4Sdf054094 for ; Tue, 18 Mar 2008 16:04:38 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from daemon.ma.sigsys.de (rabe@rabe.uugrn.org [195.49.138.102]) by rabe.uugrn.org (8.13.8/8.13.8) with ESMTP id m2IF4Shg054090 for ; Tue, 18 Mar 2008 16:04:28 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from daemon.ma.sigsys.de (localhost.ma.sigsys.de [127.0.0.1]) by daemon.ma.sigsys.de (8.14.2/8.13.1) with ESMTP id m2IF4qhM011090 for ; Tue, 18 Mar 2008 16:04:52 +0100 (CET) (envelope-from rabe@uugrn.org) Received: (from rabe@localhost) by daemon.ma.sigsys.de (8.14.2/8.14.2/Submit) id m2IF4quS011089 for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 16:04:52 +0100 (CET) (envelope-from rabe@uugrn.org) X-Authentication-Warning: daemon.ma.sigsys.de: rabe set sender to rabe@uugrn.org using -f Date: Tue, 18 Mar 2008 16:04:52 +0100 From: Raphael Becker To: freebsd-stable@freebsd.org Message-ID: <20080318150452.GA1561@ma.sigsys.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Using /etc/rc.d/geli with labeled devices on 6.3 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, 18 Mar 2008 15:29:16 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, given that /dev/ad12 is a geli encryptet device, you might set up /etc/rc.conf like geli_enable=3D"YES" geli_devices=3D"ad12" geli_ad12_flags=3D"-k /root/keys/geli.ad12.key" I don't like absolute device names (they might change) so I label them e.g. FOOcrypt so it show up like /dev/label/FOOcrypt Attaching the FOOcrypt manually works like # geli attach -k /root/geli.FOO.key /dev/label/FOOcrypt=20 Enter passphrase: The UFS on /dev/label/FOOcrypt.eli is labeled FOO[1] so=20 it will be available on /dev/ufs/FOO and can be mounted: # mount /dev/ufs/FOO How should I set up /etc/rc.conf to get this by /etc/rc.d/geli on boot? geli_enable=3D"YES" geli_devices=3D"label/FOOcrypt" geli_label/FOOcrypt_flags=3D"-k /root/keys/geli.FOO.key" ^^^^^^^^^^^^^^=20 This won't work. How? TIA. Regards Raphael Becker [1] newfs -L FOO ... /dev/label/FOOcrypt.eli --> /dev/ufs/FOO --=20 Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D =2E........|.........|.........|.........|.........|.........|.........|.. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFH39oUnNo+exDKny0RAsMMAKDIo/CqzVPHtDasexT51OajwJW+pACdFR7c n2lFbL4xKIq1frV8XOyljds= =7iJg -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 16:10:48 2008 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 C6C9E106564A for ; Tue, 18 Mar 2008 16:10:48 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 7E86D8FC15 for ; Tue, 18 Mar 2008 16:10:48 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 2fUU1Z0030Fqzac5305700; Tue, 18 Mar 2008 15:59:46 +0000 Received: from daland.home ([24.61.21.4]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 2g0m1Z00C05H7zL3U00000; Tue, 18 Mar 2008 16:00:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=mDUhab2H8L8A:10 a=rITDv7nW5hcA:10 a=BUmY6nS4aFZ3ObDiYnwA:9 a=K9iLOqqnb7zMXshCEqwA:7 a=xUAexLCCzV1GIvSgfvjGkpAgtYcA:4 a=si9q_4b84H0A:10 a=XF7b4UCPwd8A:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbeF4-0002Fb-LB for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 12:00:46 -0400 From: Alex Goncharov To: freebsd-stable@freebsd.org Message-Id: Sender: Alex Goncharov Date: Tue, 18 Mar 2008 12:00:46 -0400 Subject: Plentiful NFS debug messages in /var/log/messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 16:10:48 -0000 The system is built from source so that: ======================================== # uname -sr FreeBSD 7.0-RELEASE # cat KERNEL-CONFIG | FILTER-DEBUG options KDB options KDB_TRACE options DDB options WITNESS options WITNESS_SKIPSPIN ======================================== An NFS client (an application using an NFS file system) runs unbelievably slow, compared with when a local file system is used. The NFS server shows this: ---------------------------------------- # vmstat 4 200 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 3 0 0 142408 317124 10 0 0 0 10 0 0 69 80 409 0 1 99 2 0 0 142408 316756 0 0 0 0 0 0 1 406 3288 1336 1 99 0 2 0 0 142408 316276 0 0 0 0 4 0 5 409 4837 1350 1 98 1 2 0 0 142408 315812 168 0 0 0 143 0 6 401 5251 1341 1 98 1 0 0 0 142408 315396 0 0 0 0 44 0 25 365 4396 1252 1 80 20 0 0 0 142408 314892 0 0 0 0 27 0 34 287 2449 1101 1 37 62 0 0 0 142408 314244 0 0 0 0 16 0 18 272 1215 1051 0 20 80 0 0 0 142408 313828 0 0 0 0 6 0 14 197 545 862 0 9 91 0 0 0 142408 313236 0 0 0 0 6 0 10 232 536 933 0 9 91 0 0 0 142408 312680 0 0 0 0 10 0 14 229 977 944 1 14 85 0 0 0 142408 312208 0 0 0 0 12 0 16 216 1053 895 0 16 84 0 0 0 142408 311936 0 0 0 0 4 0 7 133 410 668 0 6 93 ---------------------------------------- These messages are meanwhile streaming into `/var/log/messages': -------------------- Mar 18 11:47:42 fasolt kernel: --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280c4a2b, esp = 0xbfbfeb2c, ebp = 0xbfb feb48 --- Mar 18 11:47:42 fasolt kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: Mar 18 11:47:42 fasolt kernel: exclusive sleep mutex nfsd_mtx r = 0 (0xc09456a0) locked @ /mnt/wdx/freebsd/7.0/usr/src/s ys/nfsserver/nfs_srvsock.c:654 KDB: stack backtrace: db_trace_self_wrapper(c08485d5,d5f1faf8,c0615eed,c084895a,d5f1fb0c,...) at db_trace_self_ kdb_backtrace(c084895a,d5f1fb0c,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c085e59c,c084c9c8,d5f1fb1c,...) at witness_warn+0x1cd uma_zalloc_arg(c1067d20,d5f1fb70,2,8,c2bf94a4,...) at uma_zalloc_arg+0x34 nfs_realign(c09456a0,0,c08595b8,28e,0,...) at nfs_realign+0x6f nfsrv_rcv(c2daf948,c2bf9480,2,160,0,...) at nfsrv_rcv+0x42a nfssvc(c2c0caa0,d5f1fcfc,8,c2c0caa0,c089eac8,...) at nfssvc+0x664 syscall(d5f1fd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 -------------------- I could, of course, rebuild the kernel without the debug options but perhaps somebody sees a problem with this behavior and can advise me on a better course of actions. Thanks, -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 16:43:22 2008 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 60AEF106566C for ; Tue, 18 Mar 2008 16:43:22 +0000 (UTC) (envelope-from samuel.w.sirlin@jpl.nasa.gov) Received: from mfbak.jpl.nasa.gov (mfbak.jpl.nasa.gov [137.78.160.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4EACD8FC22 for ; Tue, 18 Mar 2008 16:43:22 +0000 (UTC) (envelope-from samuel.w.sirlin@jpl.nasa.gov) Received: from nmta1.jpl.nasa.gov (nmta1.jpl.nasa.gov [137.78.160.214]) by mfbak.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2IFxLlo006218 for ; Tue, 18 Mar 2008 08:59:21 -0700 Received: from xmta2.jpl.nasa.gov (xmta2.jpl.nasa.gov [137.78.160.56]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2IFxJkj020663 for ; Tue, 18 Mar 2008 08:59:20 -0700 Received: from kalessin (kalessin.jpl.nasa.gov [128.149.29.130]) by xmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with SMTP id m2IFxIKx027678 for ; Tue, 18 Mar 2008 08:59:18 -0700 Date: Tue, 18 Mar 2008 08:59:17 -0700 From: sam sirlin To: freebsd-stable@freebsd.org Message-Id: <20080318085917.c7e33f43.samuel.w.sirlin@jpl.nasa.gov> In-Reply-To: <20080317211824.H3271@jago.65north.com> References: <20080317224136.8B03A4500F@ptavv.es.net> <20080317211824.H3271@jago.65north.com> Organization: jpl X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; sparc-sun-solaris2.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Source-IP: kalessin.jpl.nasa.gov [128.149.29.130] X-Source-Sender: samuel.w.sirlin@jpl.nasa.gov X-AUTH: Authorized Subject: Re: recovering from the 6.3 xorg mess 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, 18 Mar 2008 16:43:22 -0000 On Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) peter stern wrote: > On Mon, 17 Mar 2008, Kevin Oberman wrote: > >> Date: Mon, 17 Mar 2008 07:36:23 +0100 > >> From: Kurt Jaeger > >> Sender: owner-freebsd-stable@freebsd.org > >> Hi! > >>> I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > >>> shipped with. I've been using FreeBSD since 2.2 and have never had much > >>> trouble with it until the 6 branch was released. My hardware is pretty > >>> generic Intel brand D865 motherboard, matrox g550 video. I don't customize > >>> the kernel. I do clean installs not upgrades. > >> > >> Basically, the problem is with the matrox board. ... > > > > I have run the Matrox G550 under both 6 and 7. I had some problems, but > > not too many. I do need to use xrandr to set up the proper resolution, > > though. > > > > #!/bin/sh > > # Set 1280x1024 mode on second display > > xrandr --addmode VGA2 1280x1024 > > # Set 1024x768 mode on second port (Why? Why not.) > > xrandr --addmode VGA2 1024x768 > > # Set the second port to use 1280x1024 > > xrandr --output VGA2 --mode 1280x1024 ... Not unique to matrox. Some time before 6.3 there was an X update that broke various things. I also noticed I couldn't set resolution in xorg.conf or via keystrokes. xrandr seems the only way for most wm (kde can do it). I thought perhaps it was a 64bit problem since I'm using amd64, and some other keystrokes don't work (normally don't notice but was trying to find some way to set resolution). I've also noticed after xscreensaver can put X in a sleep mode where it just ignores anything (not a crash, but need to remote in to shut down X at least). Is resolution setting only through xrandr perhaps a deliberate (but undocumented) design change in xorg (feature)? Or just a temporary bug? I don't have a matrox: drm0: port 0xa000-0xa0ff mem 0xe0000000-0xe7ffffff,0xfd800000-0xfd80ffff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized radeon 1.25.0 20060524 -- sam sirlin From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 19:21:33 2008 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 EEC3A106566C for ; Tue, 18 Mar 2008 19:21:32 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from zid.claresco.hr (zid.claresco.hr [85.114.42.226]) by mx1.freebsd.org (Postfix) with ESMTP id 357C08FC1F for ; Tue, 18 Mar 2008 19:21:31 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: (qmail 54135 invoked by uid 1001); 18 Mar 2008 20:21:20 +0100 To: Kris Kennaway Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <47C749CF.4010501@FreeBSD.org> (Kris Kennaway's message of "Fri, 29 Feb 2008 00:54:55 +0100") References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> Organization: *BSD Users - Fanatics Dept. From: Marko Lerota Date: Tue, 18 Mar 2008 20:21:20 +0100 Message-ID: <86eja7et3j.fsf@zid.claresco.hr> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 18 Mar 2008 19:21:34 -0000 Kris Kennaway writes: >> Then the servers. Why should I reinstall all my databases and such? >> I always >> liked that FreeBSD base (OS) is separated from packages. And no >> matter what I do with the packages, my OS will always work. I don't >> want dependency >> hell like in Linux. Now you are telling me that my database might not work >> after upgrade to a new version. Is that it? > > First, try to relax. Sorry, but I'm pissed off now, not relax any more. > portupgrade -faP requests to reinstall everything from precompiled > packages. It will only fall back to compiling them locally if the > package is unavailable (e.g. for legal reasons). It passed two days from portupgrade -faP, and it didn't finished yet. To be worse, I have to do it again because the PC had to be rebooted. So in the next 2-3 days I can sit with my PC and wait with him to finish the upgrade. It will be three days because of Openoffice!@#!@#!@#!. And I have to pray the god that I don't have the power loss. Now apache and acroread doesn't work any more and I'm afraid that I'll find some other stuff that don't work too. So can anyone tell me this is not stupid??? Reinstalling all applications because of upgrade? This can be called new installation. Not upgrade. Now I'm thinking that It would be much easier that I backup my files, databases and other stuff and do fresh installation. But why???? So I can do the same thing when 8_0 comes out? This is the worst thing that I found about FreeBSD for now. This have to be changed or fixed somehow, because the upgrade is not possible if you have lots of ports installed, and certainly can't be called upgrade! -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 19:27:59 2008 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 08AF01065674; Tue, 18 Mar 2008 19:27:59 +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 E35E38FC21; Tue, 18 Mar 2008 19:27:58 +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.2/8.14.2) with ESMTP id m2IJRwFX079192; Tue, 18 Mar 2008 15:27:58 -0400 (EDT) (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.2/8.14.2) with ESMTP id m2IJRwLa065837; Tue, 18 Mar 2008 15:27:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 04FC01B5078; Tue, 18 Mar 2008 15:27:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080318192758.04FC01B5078@freebsd-stable.sentex.ca> Date: Tue, 18 Mar 2008 15:27:57 -0400 (EDT) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Tue, 18 Mar 2008 19:27:59 -0000 TB --- 2008-03-18 18:19:47 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-03-18 18:19:47 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-03-18 18:19:47 - cleaning the object tree TB --- 2008-03-18 18:20:02 - cvsupping the source tree TB --- 2008-03-18 18:20:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-03-18 18:20:09 - building world (CFLAGS=-O2 -pipe) TB --- 2008-03-18 18:20:09 - cd /src TB --- 2008-03-18 18:20:09 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 18 18:20:11 UTC 2008 >>> 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 Tue Mar 18 19:19:14 UTC 2008 TB --- 2008-03-18 19:19:14 - generating LINT kernel config TB --- 2008-03-18 19:19:14 - cd /src/sys/sparc64/conf TB --- 2008-03-18 19:19:14 - /usr/bin/make -B LINT TB --- 2008-03-18 19:19:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-03-18 19:19:14 - cd /src TB --- 2008-03-18 19:19:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 18 19:19:14 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -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 /src/sys/netinet/ip_dummynet.c 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 /src/sys/netinet/ip_ecn.c 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 /src/sys/netinet/ip_encap.c 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 /src/sys/netinet/ip_fastfwd.c 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 /src/sys/netinet/ip_fw2.c -I/src/sys/contrib/pf cc1: warnings being treated as errors /src/sys/netinet/ip_fw2.c: In function 'ipfw_init': /src/sys/netinet/ip_fw2.c:4507: warning: too many arguments for format *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-18 19:27:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-18 19:27:57 - ERROR: failed to build lint kernel TB --- 2008-03-18 19:27:57 - tinderbox aborted TB --- 3555.03 user 348.05 system 4090.67 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 20:22:52 2008 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 2BB4D106566C for ; Tue, 18 Mar 2008 20:22:52 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB0208FC28; Tue, 18 Mar 2008 20:22:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E0249C.8030700@FreeBSD.org> Date: Tue, 18 Mar 2008 21:22:52 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Marko Lerota References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> In-Reply-To: <86eja7et3j.fsf@zid.claresco.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 18 Mar 2008 20:22:52 -0000 Marko Lerota wrote: > Kris Kennaway writes: > >>> Then the servers. Why should I reinstall all my databases and such? >>> I always >>> liked that FreeBSD base (OS) is separated from packages. And no >>> matter what I do with the packages, my OS will always work. I don't >>> want dependency >>> hell like in Linux. Now you are telling me that my database might not work >>> after upgrade to a new version. Is that it? >> First, try to relax. > > Sorry, but I'm pissed off now, not relax any more. > >> portupgrade -faP requests to reinstall everything from precompiled >> packages. It will only fall back to compiling them locally if the >> package is unavailable (e.g. for legal reasons). > > It passed two days from portupgrade -faP, and it didn't finished yet. > To be worse, I have to do it again because the PC had to be rebooted. > So in the next 2-3 days I can sit with my PC and wait with him to > finish the upgrade. It will be three days because of Openoffice!@#!@#!@#!. Are you connected via a modem or something? 2-3 days to download some packages cannot be right if you have a decent internet connection. > And I have to pray the god that I don't have the power loss. > Now apache and acroread doesn't work any more and I'm afraid that > I'll find some other stuff that don't work too. > > So can anyone tell me this is not stupid??? Reinstalling all > applications because of upgrade? This can be called new > installation. Not upgrade. > > Now I'm thinking that It would be much easier that I backup my files, > databases and other stuff and do fresh installation. But why???? > So I can do the same thing when 8_0 comes out? > > This is the worst thing that I found about FreeBSD for now. > This have to be changed or fixed somehow, because the upgrade > is not possible if you have lots of ports installed, and > certainly can't be called upgrade! > I'm sorry you feel that way, but you haven't understood the explanations that you have been given already. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 20:54:58 2008 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 CC1AE1065671 for ; Tue, 18 Mar 2008 20:54:58 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2408FC1C for ; Tue, 18 Mar 2008 20:54:58 +0000 (UTC) (envelope-from SRS0=e70a9b93b4b0ad0d6c100e9a693e4568a743718a=644=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id YXU11456; Tue, 18 Mar 2008 13:54:56 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E23824500F; Tue, 18 Mar 2008 13:54:55 -0700 (PDT) To: Kris Kennaway In-Reply-To: Your message of "Tue, 18 Mar 2008 21:22:52 BST." <47E0249C.8030700@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1205873695_31213P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 18 Mar 2008 13:54:55 -0700 From: "Kevin Oberman" Message-Id: <20080318205455.E23824500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Kris Kennaway X-To_Domain: freebsd.org X-To: Kris Kennaway X-To_Email: kris@FreeBSD.org X-To_Alias: kris Cc: Marko Lerota , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 18 Mar 2008 20:54:59 -0000 --==_Exmh_1205873695_31213P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Tue, 18 Mar 2008 21:22:52 +0100 > From: Kris Kennaway > Sender: owner-freebsd-stable@freebsd.org > > Marko Lerota wrote: > > Kris Kennaway writes: > > > >>> Then the servers. Why should I reinstall all my databases and such? > >>> I always > >>> liked that FreeBSD base (OS) is separated from packages. And no > >>> matter what I do with the packages, my OS will always work. I don't > >>> want dependency > >>> hell like in Linux. Now you are telling me that my database might not work > >>> after upgrade to a new version. Is that it? > >> First, try to relax. > > > > Sorry, but I'm pissed off now, not relax any more. > > > >> portupgrade -faP requests to reinstall everything from precompiled > >> packages. It will only fall back to compiling them locally if the > >> package is unavailable (e.g. for legal reasons). > > > > It passed two days from portupgrade -faP, and it didn't finished yet. > > To be worse, I have to do it again because the PC had to be rebooted. > > So in the next 2-3 days I can sit with my PC and wait with him to > > finish the upgrade. It will be three days because of Openoffice!@#!@#!@#!. > > Are you connected via a modem or something? 2-3 days to download some > packages cannot be right if you have a decent internet connection. > > > And I have to pray the god that I don't have the power loss. > > Now apache and acroread doesn't work any more and I'm afraid that > > I'll find some other stuff that don't work too. > > > > So can anyone tell me this is not stupid??? Reinstalling all > > applications because of upgrade? This can be called new > > installation. Not upgrade. > > > > Now I'm thinking that It would be much easier that I backup my files, > > databases and other stuff and do fresh installation. But why???? > > So I can do the same thing when 8_0 comes out? > > > > This is the worst thing that I found about FreeBSD for now. > > This have to be changed or fixed somehow, because the upgrade > > is not possible if you have lots of ports installed, and > > certainly can't be called upgrade! > > > > I'm sorry you feel that way, but you haven't understood the explanations > that you have been given already. Or, is the system failing to retrieve the packages and failing over to building the ports? This would take a long time! I always tee the output of portupgrade to a file so, if it dies in the middle, it's pretty easy to pick up where it left off and not re-build everything twice. -- 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 --==_Exmh_1205873695_31213P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH4Cwfkn3rs5h7N1ERAk+yAJ43fypkGNe4Xy+jJb77PfXIV4x6tQCfUgrx 4/wLxCUTZOJeeLUgF8eWBLY= =tUYa -----END PGP SIGNATURE----- --==_Exmh_1205873695_31213P-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 21:04:35 2008 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 C4BD11065675 for ; Tue, 18 Mar 2008 21:04:35 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D238F8FC13; Tue, 18 Mar 2008 21:04:34 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E02E64.1090102@FreeBSD.org> Date: Tue, 18 Mar 2008 22:04:36 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kevin Oberman References: <20080318205455.E23824500F@ptavv.es.net> In-Reply-To: <20080318205455.E23824500F@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marko Lerota , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 18 Mar 2008 21:04:35 -0000 Kevin Oberman wrote: > Or, is the system failing to retrieve the packages and failing over to > building the ports? This would take a long time! > > I always tee the output of portupgrade to a file so, if it dies in the > middle, it's pretty easy to pick up where it left off and not re-build > everything twice. Yes, also I am pretty sure that if you rerun portupgrade -faP a second time it will reuse the cached packages it downloaded last time, if they are not out of date. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 22:11:58 2008 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 35A8C1065670 for ; Tue, 18 Mar 2008 22:11:58 +0000 (UTC) (envelope-from vibarus@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7A18FC21 for ; Tue, 18 Mar 2008 22:11:58 +0000 (UTC) (envelope-from vibarus@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 25so93040wfa.7 for ; Tue, 18 Mar 2008 15:11:57 -0700 (PDT) Received: by 10.142.226.2 with SMTP id y2mr1506411wfg.137.1205876629903; Tue, 18 Mar 2008 14:43:49 -0700 (PDT) Received: by 10.142.246.20 with HTTP; Tue, 18 Mar 2008 14:43:49 -0700 (PDT) Message-ID: Date: Tue, 18 Mar 2008 22:43:49 +0100 From: "Vincent Barus" To: "Marko Lerota" In-Reply-To: <86eja7et3j.fsf@zid.claresco.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 18 Mar 2008 22:11:58 -0000 On Tue, Mar 18, 2008 at 8:21 PM, Marko Lerota wrote: > Kris Kennaway writes: > > >> Then the servers. Why should I reinstall all my databases and such? > >> I always > >> liked that FreeBSD base (OS) is separated from packages. And no > >> matter what I do with the packages, my OS will always work. I don't > >> want dependency > >> hell like in Linux. Now you are telling me that my database might not work > >> after upgrade to a new version. Is that it? > > > > First, try to relax. > > Sorry, but I'm pissed off now, not relax any more. > > > > portupgrade -faP requests to reinstall everything from precompiled > > packages. It will only fall back to compiling them locally if the > > package is unavailable (e.g. for legal reasons). > > It passed two days from portupgrade -faP, and it didn't finished yet. > To be worse, I have to do it again because the PC had to be rebooted. > So in the next 2-3 days I can sit with my PC and wait with him to > finish the upgrade. It will be three days because of Openoffice!@#!@#!@#!. > And I have to pray the god that I don't have the power loss. > Now apache and acroread doesn't work any more and I'm afraid that > I'll find some other stuff that don't work too. > > So can anyone tell me this is not stupid??? Reinstalling all > applications because of upgrade? This can be called new > installation. Not upgrade. > > Now I'm thinking that It would be much easier that I backup my files, > databases and other stuff and do fresh installation. But why???? > So I can do the same thing when 8_0 comes out? > > This is the worst thing that I found about FreeBSD for now. > This have to be changed or fixed somehow, because the upgrade > is not possible if you have lots of ports installed, and > certainly can't be called upgrade! > > > -- > One cannot sell the earth upon which the people walk > Tacunka Witco > _______________________________________________ > > > 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" > Hi Marko, you can always use the -w flag of portupgrade if interrupted it while upgrading the installed ports: ------------ w --noclean Do not "make clean" before each build. See the -c option above. ------------ If you start the portupgrade again without -w then it will use -c by default which means all your "inbuildproccess" ports are gone. I don't know if -w is the clean way to resume from an interrupted portupgrade, but i never had problems with it. Well, ok you mustn't install any other port before you resume your portupgrade that could confuse your system :) The more clean and easy way to do a upgrade of your ports after switching to another major release (I do it this way everytime): #pkg_delete -fa <--- is much faster than pkg_deinstall Then i get my Ports with the -P flag of portinstall. A few days ago I did it this way after I jumped from 7 Release to 7 Stable. It took me about three hours to get my x11-wm/xfce4, x11/xorg (yes the complete xorg) and some other tools I need to work because the biggest part of this ports were available as prebuild pkgs. Try it this way, Vincent From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 22:39:50 2008 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 24862106566C for ; Tue, 18 Mar 2008 22:39:50 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from caillean.shopkeeper.de (caillean.shopkeeper.de [82.119.175.19]) by mx1.freebsd.org (Postfix) with ESMTP id B212D8FC1B for ; Tue, 18 Mar 2008 22:39:49 +0000 (UTC) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (p54B85433.dip.t-dialin.net [84.184.84.51]) (authenticated bits=0) by caillean.shopkeeper.de (8.13.8/8.13.4) with ESMTP id m2IMdius032033; Tue, 18 Mar 2008 23:39:46 +0100 (CET) (envelope-from sascha@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.2/8.12.11) with ESMTP id m2IMdigh069890; Tue, 18 Mar 2008 23:39:44 +0100 (CET) (envelope-from sascha@avalon.dobu.local) Received: (from sascha@localhost) by avalon.dobu.local (8.14.2/8.14.2/Submit) id m2IMdfi0069889; Tue, 18 Mar 2008 23:39:41 +0100 (CET) (envelope-from sascha) Date: Tue, 18 Mar 2008 23:39:41 +0100 From: Sascha Klauder To: Vivek Khera Message-ID: <20080318223941.GA69840@trimind.de> References: <20080317200532.GA942@trimind.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.92.1/6288/Tue Mar 18 11:43:22 2008 on caillean.shopkeeper.de X-Virus-Status: Clean Cc: FreeBSD Stable Subject: Re: hifn(4) causing system lockup 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, 18 Mar 2008 22:39:50 -0000 On Tue, Mar 18, 2008 at 10:25:03AM -0400, Vivek Khera wrote: > On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: > >I've got a Soekris vpn1401 card to help with GELI disk en- > >cryption. Reading from a GELI volume is causing the system to > >freeze completely, which does not happen if software crypto is > >used (i.e. hifn.ko not loaded). I can't enter kernel debugger > >(ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu > >isn't up to par anyway. > > I've had the exact same kind of issue with the vpn1401 PCI card in a > Dell box for my firewall running pfSense (at the tie it was based on > FreeBSD 6.1 I believe). It would lock up the firewall within 2 hours > to 4 days of uptime. Once we removed the card, no lockups. Soekris > never responded to my questions about such behavior. Interesting. But then, like I already wrote, I had it running fine for months on 6.2-STABLE. Now that both 6.3 and 7.0 exhibit this lockup behaviour, I naturally suspected some issue with the driver, even more so since revision 1.40 seems to have brought in several changes. > I blame the card. Hmpf. Cheers, -sascha From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 22:49:36 2008 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 0949A106566B for ; Tue, 18 Mar 2008 22:49:36 +0000 (UTC) (envelope-from danny@ricin.com) Received: from smtpq1.tilbu1.nb.home.nl (smtpq1.tilbu1.nb.home.nl [213.51.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id A3EBE8FC18 for ; Tue, 18 Mar 2008 22:49:35 +0000 (UTC) (envelope-from danny@ricin.com) Received: from [213.51.146.189] (port=50844 helo=smtp2.tilbu1.nb.home.nl) by smtpq1.tilbu1.nb.home.nl with esmtp (Exim 4.60) (envelope-from ) id 1Jbk1P-0000I8-9U for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 23:11:03 +0100 Received: from [84.27.119.97] (port=61715 helo=desktop.homenet) by smtp2.tilbu1.nb.home.nl with smtp (Exim 4.60) (envelope-from ) id 1Jbk1O-00071b-Ip for freebsd-stable@freebsd.org; Tue, 18 Mar 2008 23:11:03 +0100 Received: by desktop.homenet (sSMTP sendmail emulation); Tue, 18 Mar 2008 23:09:46 +0100 From: "Danny Pansters" To: freebsd-stable@freebsd.org Date: Tue, 18 Mar 2008 23:09:46 +0100 User-Agent: KMail/1.9.7 References: <000e01c8885f$d78bc070$26714dd1@syix.com> <47DECC95.2030608@moneybookers.com> In-Reply-To: <47DECC95.2030608@moneybookers.com> X-Face: (Zs+'ncTcchkOX|~t6{?Iii=O!G#WEK!+OD0|-F=i%1pvP5V_Sz4PaJC8o)=?utf-8?q?MiSnH/JMJFy=0A=09oBN-My?=, v":S7, (=?utf-8?q?mmkPm=27U=7BMgT+eM=2EBd=5Cp/P!dr=5DhOTXqpse21O!=25Ct=60SE=2EOodq?= =?utf-8?q?=5Dry=5E=23kU=5E=0A=09-?=GT.[8D}i$6P>=" =?utf-8?q?=23=0A=09*J+4d=7E?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803182309.46931.danny@ricin.com> X-Spam-Score: 0.0 (/) Subject: Re: +rtfree: 0xffffff0003635780 has 1 refs 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, 18 Mar 2008 22:49:36 -0000 On Monday 17 March 2008 20:55:01 Stefan Lambrev wrote: > Greetings Dave, > > Dave Overton wrote: > > I am new to the AMD64 stable branch, so forgive me if this has been beat > > to death, but I can't find why this message keeps occurring over and over > > all day. FreeBSD 7.0 Stable on AMD x2. It works (or seems to) fine. > > > > +rtfree: 0xffffff0003635780 has 1 refs > > check google for rtfree() used when RTFREE() needed .. or something like > this :) > Those messages are annoying but harmless. Harmless perhaps, but it still should be fixed, so if you don't see any similar PR already I'd suggest sending one. Has to do with certain variables being of one type but used as if it were another (e.g. int vs long) which on 64bit platforms as a band-aid gets "MSB-filled" with 0xf's to the proper size. So such warning pretty much means "fix your code". HTH, Dan > > its a kernel "bold" on the terminal, and would scare me to death if I > > just knew what it meant... > > > > Should I be worried about something? I hate bold white text.... > > > > > > > > Dave Overton, Owner > > SYIX.COM > > > > dave@syix.com > > (530) 755-1751 x101 > > Fax (530) 751-8871 > > 800-988-SYIX > > > > _______________________________________________ > > 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 Tue Mar 18 22:50:47 2008 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 8E0D1106566B for ; Tue, 18 Mar 2008 22:50:47 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 82BCE8FC15 for ; Tue, 18 Mar 2008 22:50:47 +0000 (UTC) (envelope-from mi+mill@aldan.algebra.com) Received: (qmail 3514 invoked from network); 18 Mar 2008 22:50:47 -0000 Received: from aldan.algebra.com ([216.254.65.224]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Mar 2008 22:50:46 -0000 From: Mikhail Teterin To: stable@freebsd.org Date: Tue, 18 Mar 2008 18:50:45 -0400 User-Agent: KMail/1.7.1 Organization: Virtual Estates, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803181850.45637.mi+mill@aldan.algebra.com> Cc: Subject: FreeBSD-4 executables on 7.x/amd64 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, 18 Mar 2008 22:50:47 -0000 Hello! I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable. It dies on startup with "bad system call". The core shows, that it is simply trying to mmap something. I have the following COMPAT-options enabled in my kernel: options COMPAT_43 # Needed by COMPAT_LINUX32 options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_LINUX32 # Compatible with i386 linux binaries Should not that be enough? Thanks! -mi (gdb) where #0 0x284c65a4 in __syscall () from /opt/lib32/compat/libc_r.so.4 #1 0x285155af in mmap () from /opt/lib32/compat/libc_r.so.4 #2 0x285143a1 in _thread_leave_cancellation_point () from /opt/lib32/compat/libc_r.so.4 #3 0x28514ef6 in malloc () from /opt/lib32/compat/libc_r.so.4 #4 0x284db240 in _pq_alloc () from /opt/lib32/compat/libc_r.so.4 #5 0x284df1a6 in _thread_init () from /opt/lib32/compat/libc_r.so.4 #6 0x284deca7 in _get_curthread () from /opt/lib32/compat/libc_r.so.4 #7 0x284dc2f2 in pthread_mutex_lock () from /opt/lib32/compat/libc_r.so.4 #8 0x28468675 in __register_frame_info () from /opt/lib32/compat/libstdc++.so.3 #9 0x2849e8b2 in ?? () from /opt/lib32/compat/libc_r.so.4 #10 0x2852366c in _thread_autoinit_dummy_decl () from /opt/lib32/compat/libc_r.so.4 #11 0x28524720 in ?? () from /opt/lib32/compat/libc_r.so.4 #12 0x283732b4 in ?? () #13 0x2849e88c in ?? () from /opt/lib32/compat/libc_r.so.4 #14 0x283732b4 in ?? () #15 0x00000008 in ?? () #16 0xffffdbe4 in ?? () #17 0xffffda38 in ?? () #18 0x283732b4 in ?? () #19 0x2834e97b in ?? () from /usr/libexec/ld-elf.so.1 #20 0xffffda58 in ?? () #21 0x2849b61d in _init () from /opt/lib32/compat/libc_r.so.4 #22 0x283513af in _rtld_error () from /usr/libexec/ld-elf.so.1 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 18 23:01:12 2008 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 BEAC3106566B for ; Tue, 18 Mar 2008 23:01:12 +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 64C5A8FC1A for ; Tue, 18 Mar 2008 23:01:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5C9E628457 for ; Wed, 19 Mar 2008 07:01:11 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 856FFEB5AD2; Wed, 19 Mar 2008 07:01:10 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id WbLraO6DZsQS; Wed, 19 Mar 2008 07:01:04 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 821A1EB4701; Wed, 19 Mar 2008 07:01:03 +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=ZZ4prRoBVhPpi2Pir314ec4VZyXjV28xLS5/sV0wypES7bji0etFrxcFZIzU/6a2/ 6G5Dl0bbpHP6fHvOx1ZEQ== Message-ID: <47E049AC.5010803@delphij.net> Date: Tue, 18 Mar 2008 16:01:00 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080312) MIME-Version: 1.0 To: Mikhail Teterin References: <200803181850.45637.mi+mill@aldan.algebra.com> In-Reply-To: <200803181850.45637.mi+mill@aldan.algebra.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: FreeBSD-4 executables on 7.x/amd64 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: Tue, 18 Mar 2008 23:01:12 -0000 Mikhail Teterin wrote: > Hello! > > I have a 7.0 system (amd64) and am trying to run a FreeBSD-4 executable. > It dies on startup with "bad system call". The core shows, that it is > simply trying to mmap something. > > I have the following COMPAT-options enabled in my kernel: > > options COMPAT_43 # Needed by COMPAT_LINUX32 > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_LINUX32 # Compatible with i386 linux binaries > > Should not that be enough? Thanks! Only a guess: add COMPAT_FREEBSD6 and try again? date: 2007/07/04 22:47:37; author: peter; state: Exp; lines: +20 -9 Create new syscalls for mmap(), lseek(), pread(), pwrite(), truncate() and ftruncate(), but without the pad arg. There are several reasons for this. Consider 'mmap()'. On AMD64, the function call (and syscall) ABI allow for 6 register arguments. Additional arguments go on the stack. mmap(2) has 6 arguments. However, the syscall definition has an extra 'int pad' argument. This pushes it to 7 arguments, which means one must spill into the memory stack. Since the kernel API doesn't match userland API, we have a hack in libc - libc/sys/mmap.c. This implements the userland API by calling __syscall() with an extra argument and the pad argument, for a total of 8 args. This is all unnecessary and inconvenient for several things, including the kernel's syscall handler code which now has to handle merging stack arguments with register arguments. It is a big deal for certain 3rd party code. I'm adding libc glue to make the transition totally painless. I had intended to mark the old syscalls as COMPAT6, but the potential to shoot your feet by building a new kernel without COMPAT_FREEBSD6 but with a slighly older userland was too great. For now, they have manual "freebsd6_" prefixes rather than being COMPAT6. They will go back to being marked 'COMPAT6' after 7-stable starts. Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 05:07:09 2008 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 E54E9106566B for ; Wed, 19 Mar 2008 05:07:09 +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 AACCD8FC15 for ; Wed, 19 Mar 2008 05:07:09 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2J4TRR5095360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 21:29:28 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47E096A7.9080700@freebsd.org> Date: Tue, 18 Mar 2008 21:29:27 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Vivek Khera References: <20080317200532.GA942@trimind.de> 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 Stable Subject: Re: hifn(4) causing system lockup 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, 19 Mar 2008 05:07:10 -0000 Vivek Khera wrote: > > On Mar 17, 2008, at 4:05 PM, Sascha Klauder wrote: > >> I've recently upgraded my 6.2-STABLE workstation to RELENG_7, >> and I'm now experiencing system lockups that seem to be caused >> by the hifn(4) driver. >> >> I've got a Soekris vpn1401 card to help with GELI disk en- >> cryption. Reading from a GELI volume is causing the system to >> freeze completely, which does not happen if software crypto is >> used (i.e. hifn.ko not loaded). I can't enter kernel debugger >> (ctrl+alt+esc doesn't work anymore) and my (remote) kgdb-fu >> isn't up to par anyway. > > I've had the exact same kind of issue with the vpn1401 PCI card in a > Dell box for my firewall running pfSense (at the tie it was based on > FreeBSD 6.1 I believe). It would lock up the firewall within 2 hours to > 4 days of uptime. Once we removed the card, no lockups. Soekris never > responded to my questions about such behavior. > > In contrast, their mini-PCI cards I have installed on some WRAP boards > never lockup using the same software. > > I blame the card. Hifn contributed driver changes that purportedly corrected some issues that might be related. Unfortunately I've had no time to integrate them (it was provided as a single (huge) patch w/o any explanation). I called several times for someone to take it over but noone's stepped up. If you want to work through it contact me offline. Sam From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 06:47:56 2008 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 DCFAA106566C; Wed, 19 Mar 2008 06:47:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 94FDF8FC19; Wed, 19 Mar 2008 06:47:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id RAA24750; Wed, 19 Mar 2008 17:32:00 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 19 Mar 2008 17:31:59 +1100 (EST) From: Ian Smith To: Kris Kennaway In-Reply-To: <47E02E64.1090102@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marko Lerota , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 06:47:57 -0000 On Tue, 18 Mar 2008, Kris Kennaway wrote: > Kevin Oberman wrote: > > > Or, is the system failing to retrieve the packages and failing over to > > building the ports? This would take a long time! > > > > I always tee the output of portupgrade to a file so, if it dies in the > > middle, it's pretty easy to pick up where it left off and not re-build > > everything twice. Yep, or use script(1). Amazing what you pick up from the handbook :) > Yes, also I am pretty sure that if you rerun portupgrade -faP a second > time it will reuse the cached packages it downloaded last time, if they > are not out of date. I've sometimes had some trouble with some of the mirrors not always having [all] the packages needed, and have had to shop around a bit. Running portupgrade -anPP will pick up at least all top-level packages available first, and you can check your script output (and what's in /usr/ports/packages) to be sure you've got X, KDE and other Big Stuff. Then even the bandwidth- and/or CPU-impaired are good to go with -faP. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 09:32:09 2008 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 DDC551065674 for ; Wed, 19 Mar 2008 09:32:09 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id AEC858FC32 for ; Wed, 19 Mar 2008 09:32:08 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 084D810E53B for ; Wed, 19 Mar 2008 10:00:45 +0100 (CET) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgE9j68GrA6n for ; Wed, 19 Mar 2008 10:00:34 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id 7F87910E52D for ; Wed, 19 Mar 2008 10:00:34 +0100 (CET) Date: Wed, 19 Mar 2008 10:01:48 +0100 From: Charlie Root X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <669936444.20080319100148@rulez.sk> To: stable@freebsd.org Resent-from: Daniel Gerzo MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------D11701C226D64ECE" Resent-Message-Id: <20080319090034.7F87910E52D@virtual.micronet.sk> Resent-Date: Wed, 19 Mar 2008 10:00:34 +0100 (CET) Cc: Subject: Weird system cpu usage 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, 19 Mar 2008 09:32:10 -0000 ------------D11701C226D64ECE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have to report, that I have a very strange cpu usage by system (as the `top' reports). The given box does not currently run any threaded applications (only lighttpd and php-fcgi with 80 children, maybe 100 reqs/s), but I can see the same behavior on almost identical machine which is running mysqld (Threads: 100 Questions: 36641597 Slow queries: 620 Opens: 1139 Flush tables: 1 Open tables: 1112 Queries per second avg: 584.349). Attached, I am providing dmesg.boot of the given system and an output of `top -CSaIud 10'. I have to note, that the system does not have I/O problems, the only thing that might be related is an interrupt strom on irq22, which is being shared by em1 and atapci0 (but the top's interrupt column doesn't report too high interrupt cpu usage). Both of the machines have this interrupt problem. root@[ha-web1 ~]# vmstat -i interrupt total rate irq1: atkbd0 12 0 irq16: ohci0 1 0 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci4 1 0 irq20: em0 86255835 1361 irq22: em1 atapci0 18611379049 293795 cpu0: timer 126702021 2000 cpu1: timer 126701933 2000 Total 18951038853 299157 Any hints on what might be going on are welcome. Thank you. -- Sincerely, Daniel Gerzo ------------D11701C226D64ECE Content-Type: TEXT/PLAIN; name="top.txt" Content-transfer-encoding: 8bit Content-Disposition: attachment; filename="top.txt" last pid: 15637; load averages: 5.04, 5.16, 6.19 up 0+17:16:40 09:36:52 166 processes: 3 running, 148 sleeping, 15 waiting Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2554M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:19 33.98% [idle: cpu1] 11 0 1 171 ki31 0K 16K CPU0 0 518:21 30.96% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 0 20:48 2.49% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15425 80 1 4 0 379M 24952K accept 1 0:20 1.37% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24496K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15502 80 1 4 0 379M 24420K accept 1 0:17 1.37% /usr/local/bin/php-cgi 15450 80 1 4 0 378M 24828K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24684K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K sbwait 0 0:18 1.27% /usr/local/bin/php-cgi 15471 80 1 4 0 378M 24300K accept 0 0:18 1.27% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15480 80 1 4 0 378M 23488K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15503 80 1 4 0 379M 24580K sbwait 1 0:17 1.27% /usr/local/bin/php-cgi 15506 80 1 4 0 378M 23048K accept 1 0:16 1.27% /usr/local/bin/php-cgi 15512 80 1 4 0 378M 23200K sbwait 0 0:16 1.27% /usr/local/bin/php-cgi 15423 80 1 4 0 379M 23368K accept 1 0:22 1.17% /usr/local/bin/php-cgi 15426 80 1 4 0 378M 22864K accept 1 0:21 1.17% /usr/local/bin/php-cgi 15442 80 1 4 0 378M 23204K accept 0 0:19 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 5.04, 5.16, 6.19 up 0+17:16:42 09:36:54 166 processes: 4 running, 147 sleeping, 15 waiting CPU states: 16.4% user, 0.0% nice, 44.2% system, 0.4% interrupt, 39.1% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2554M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:20 35.35% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:22 32.18% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 0 20:48 2.59% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15502 80 1 4 0 379M 24420K accept 1 0:17 1.46% /usr/local/bin/php-cgi 15450 80 1 4 0 378M 24828K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24684K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 0 0:18 1.27% /usr/local/bin/php-cgi 15471 80 1 4 0 378M 24300K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 1 0:17 1.27% /usr/local/bin/php-cgi 15425 80 1 4 0 379M 24952K sbwait 0 0:20 1.17% /usr/local/bin/php-cgi 15442 80 1 4 0 378M 23204K accept 1 0:19 1.17% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:18 1.17% /usr/local/bin/php-cgi 15461 80 1 4 0 379M 24676K accept 0 0:18 1.17% /usr/local/bin/php-cgi 15418 80 1 4 0 378M 23988K accept 1 0:21 1.07% /usr/local/bin/php-cgi 15431 80 1 4 0 379M 26100K accept 1 0:21 1.07% /usr/local/bin/php-cgi 15428 80 1 4 0 378M 23472K accept 1 0:21 1.07% /usr/local/bin/php-cgi 15426 80 1 4 0 378M 22864K accept 1 0:21 1.07% /usr/local/bin/php-cgi 15430 80 1 4 0 378M 23840K accept 1 0:20 1.07% /usr/local/bin/php-cgi last pid: 15637; load averages: 5.12, 5.17, 6.18 up 0+17:16:44 09:36:56 166 processes: 10 running, 141 sleeping, 15 waiting CPU states: 17.6% user, 0.0% nice, 62.9% system, 0.0% interrupt, 19.5% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:21 33.40% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:23 29.49% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 1 20:48 2.29% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15502 80 1 4 0 379M 24420K accept 1 0:17 1.46% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 0 0:18 1.37% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15518 80 1 4 0 378M 24472K accept 1 0:16 1.37% /usr/local/bin/php-cgi 15450 80 1 4 0 378M 24828K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24684K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15452 80 1 45 0 379M 25160K RUN 0 0:19 1.27% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15503 80 1 44 0 379M 24580K RUN 0 0:17 1.27% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 0 0:17 1.27% /usr/local/bin/php-cgi 15418 80 1 4 0 378M 23988K accept 0 0:21 1.17% /usr/local/bin/php-cgi 15442 80 1 4 0 378M 23204K accept 1 0:20 1.17% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.17% /usr/local/bin/php-cgi 15471 80 1 4 0 378M 24300K accept 1 0:18 1.17% /usr/local/bin/php-cgi 15500 80 1 4 0 379M 25068K accept 1 0:17 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 5.12, 5.17, 6.18 up 0+17:16:46 09:36:58 166 processes: 6 running, 145 sleeping, 15 waiting CPU states: 19.5% user, 0.0% nice, 52.7% system, 0.4% interrupt, 27.4% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:21 32.86% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:23 29.59% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 1 20:48 2.49% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15502 80 1 4 0 379M 24420K accept 0 0:17 1.37% /usr/local/bin/php-cgi 15426 80 1 -4 0 378M 22864K RUN 1 0:21 1.27% /usr/local/bin/php-cgi 15425 80 1 4 0 379M 24952K accept 1 0:21 1.27% /usr/local/bin/php-cgi 15450 80 1 4 0 378M 24828K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 0 0:18 1.27% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15501 80 1 4 0 378M 24812K sbwait 1 0:18 1.27% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 1 0:17 1.27% /usr/local/bin/php-cgi 15445 80 1 4 0 378M 23340K sbwait 0 0:19 1.17% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24684K accept 1 0:19 1.17% /usr/local/bin/php-cgi 15477 80 1 4 0 379M 25240K accept 1 0:18 1.17% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:18 1.17% /usr/local/bin/php-cgi 15503 80 1 4 0 379M 24580K sbwait 1 0:17 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 5.12, 5.17, 6.18 up 0+17:16:48 09:37:00 166 processes: 4 running, 147 sleeping, 15 waiting CPU states: 26.7% user, 0.0% nice, 62.2% system, 0.2% interrupt, 10.9% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:21 29.30% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:23 27.49% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 0 20:48 2.78% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15468 80 1 4 0 379M 24796K accept 0 0:19 1.56% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.46% /usr/local/bin/php-cgi 15479 80 1 4 0 378M 23620K accept 0 0:18 1.46% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15425 80 1 4 0 379M 24952K accept 0 0:21 1.27% /usr/local/bin/php-cgi 15464 80 1 4 0 378M 22484K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15445 80 1 4 0 378M 23340K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15473 80 1 4 0 378M 23960K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15501 80 1 4 0 378M 24812K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15502 80 1 4 0 379M 24420K sbwait 1 0:17 1.27% /usr/local/bin/php-cgi 15488 80 1 4 0 378M 21548K accept 1 0:17 1.27% /usr/local/bin/php-cgi 15503 80 1 4 0 379M 24580K accept 0 0:17 1.27% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 0 0:17 1.27% /usr/local/bin/php-cgi last pid: 15637; load averages: 4.95, 5.14, 6.17 up 0+17:16:50 09:37:02 166 processes: 3 running, 148 sleeping, 15 waiting CPU states: 19.5% user, 0.0% nice, 50.6% system, 0.6% interrupt, 29.3% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:22 29.79% [idle: cpu1] 11 0 1 171 ki31 0K 16K CPU0 0 518:24 27.49% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 0 20:48 2.59% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15506 80 1 4 0 379M 23172K accept 1 0:17 1.86% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.46% /usr/local/bin/php-cgi 15468 80 1 4 0 379M 24796K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15479 80 1 4 0 378M 23620K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15515 80 1 4 0 378M 23916K accept 1 0:17 1.37% /usr/local/bin/php-cgi 15426 80 1 4 0 378M 22864K accept 1 0:21 1.27% /usr/local/bin/php-cgi 15425 80 1 4 0 379M 24952K accept 1 0:21 1.27% /usr/local/bin/php-cgi 15454 80 1 4 0 379M 24356K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15451 80 1 4 0 379M 25916K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15516 80 1 4 0 379M 24636K accept 1 0:17 1.27% /usr/local/bin/php-cgi 15512 80 1 4 0 378M 23720K accept 1 0:17 1.27% /usr/local/bin/php-cgi 15430 80 1 4 0 378M 23840K accept 1 0:20 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 4.95, 5.14, 6.17 up 0+17:16:52 09:37:04 166 processes: 5 running, 146 sleeping, 15 waiting CPU states: 17.0% user, 0.0% nice, 57.1% system, 1.5% interrupt, 24.3% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:23 29.59% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:24 26.56% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 1 20:49 2.88% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15469 80 1 4 0 379M 24464K accept 1 0:19 1.56% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 0 0:17 1.56% /usr/local/bin/php-cgi 15454 80 1 4 0 379M 24356K accept 0 0:19 1.37% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15479 80 1 4 0 378M 23620K accept 0 0:18 1.37% /usr/local/bin/php-cgi 15516 80 1 4 0 379M 24636K accept 1 0:17 1.37% /usr/local/bin/php-cgi 15425 80 1 4 0 379M 24952K accept 1 0:21 1.27% /usr/local/bin/php-cgi 15463 80 1 4 0 379M 25348K sbwait 1 0:19 1.27% /usr/local/bin/php-cgi 15468 80 1 4 0 379M 24796K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24772K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25844K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15512 80 1 4 0 378M 23720K accept 0 0:17 1.27% /usr/local/bin/php-cgi 15430 80 1 4 0 378M 23840K accept 1 0:20 1.17% /usr/local/bin/php-cgi 15456 80 1 4 0 379M 24012K accept 1 0:20 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 4.55, 5.05, 6.13 up 0+17:16:54 09:37:06 166 processes: 7 running, 144 sleeping, 15 waiting CPU states: 18.4% user, 0.0% nice, 51.3% system, 1.9% interrupt, 28.4% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:23 29.30% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:25 27.20% [idle: cpu0] 1425 80 1 4 0 39968K 21568K RUN 1 20:49 3.27% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15469 80 1 4 0 379M 24464K accept 1 0:19 1.56% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 1 0:17 1.56% /usr/local/bin/php-cgi 15473 80 1 4 0 378M 23960K accept 0 0:19 1.46% /usr/local/bin/php-cgi 15479 80 1 4 0 378M 23620K accept 1 0:18 1.37% /usr/local/bin/php-cgi 15516 80 1 4 0 379M 24636K accept 1 0:17 1.37% /usr/local/bin/php-cgi 15456 80 1 4 0 379M 24012K accept 1 0:20 1.27% /usr/local/bin/php-cgi 15454 80 1 4 0 379M 24356K sbwait 1 0:19 1.27% /usr/local/bin/php-cgi 15468 80 1 4 0 379M 24796K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24772K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K accept 0 0:19 1.27% /usr/local/bin/php-cgi 15458 80 1 4 0 378M 23680K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K accept 1 0:19 1.27% /usr/local/bin/php-cgi 15482 80 1 4 0 379M 25848K accept 1 0:18 1.27% /usr/local/bin/php-cgi 15422 80 1 45 0 379M 24648K RUN 0 0:23 1.17% /usr/local/bin/php-cgi 15424 80 1 4 0 378M 23604K accept 0 0:21 1.17% /usr/local/bin/php-cgi last pid: 15637; load averages: 4.55, 5.05, 6.13 up 0+17:16:56 09:37:08 166 processes: 18 running, 133 sleeping, 15 waiting CPU states: 25.2% user, 0.0% nice, 69.0% system, 0.4% interrupt, 5.5% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:23 26.17% [idle: cpu1] 11 0 1 171 ki31 0K 16K RUN 0 518:25 21.58% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 1 20:49 3.08% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15472 80 1 4 0 379M 24536K accept 1 0:19 1.66% /usr/local/bin/php-cgi 15486 80 1 -4 0 378M 21440K RUN 0 0:18 1.66% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24772K accept 1 0:19 1.56% /usr/local/bin/php-cgi 15481 80 1 4 0 378M 23180K accept 1 0:18 1.56% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.46% /usr/local/bin/php-cgi 15463 80 1 4 0 379M 25436K accept 1 0:19 1.46% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K RUN 1 0:19 1.46% /usr/local/bin/php-cgi 15506 80 1 4 0 379M 23172K accept 1 0:17 1.46% /usr/local/bin/php-cgi 15445 80 1 4 0 378M 23340K accept 0 0:19 1.37% /usr/local/bin/php-cgi 15447 80 1 4 0 378M 23800K accept 0 0:19 1.37% /usr/local/bin/php-cgi 15473 80 1 4 0 378M 23960K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15477 80 1 4 0 379M 25240K accept 0 0:19 1.37% /usr/local/bin/php-cgi 15476 80 1 4 0 378M 22972K sbwait 1 0:19 1.37% /usr/local/bin/php-cgi 15482 80 1 -4 0 379M 25976K RUN 0 0:18 1.37% /usr/local/bin/php-cgi 15423 80 1 -4 0 379M 23368K RUN 0 0:22 1.27% /usr/local/bin/php-cgi last pid: 15637; load averages: 4.55, 5.05, 6.13 up 0+17:16:58 09:37:10 166 processes: 3 running, 148 sleeping, 15 waiting CPU states: 16.3% user, 0.0% nice, 57.1% system, 0.4% interrupt, 26.2% idle Mem: 317M Active, 740M Inact, 249M Wired, 48M Cache, 214M Buf, 2553M Free Swap: 8192M Total, 8K Used, 8192M Free PID UID THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 10 0 1 171 ki31 0K 16K RUN 1 501:24 26.46% [idle: cpu1] 11 0 1 171 ki31 0K 16K CPU0 0 518:25 23.29% [idle: cpu0] 1425 80 1 4 0 39968K 21568K kqread 0 20:49 2.39% /usr/local/sbin/lighttpd -f /usr/local/etc/lighttpd.conf 15486 80 1 4 0 378M 21440K accept 0 0:18 1.86% /usr/local/bin/php-cgi 15452 80 1 4 0 379M 25160K sbwait 1 0:19 1.56% /usr/local/bin/php-cgi 15481 80 1 4 0 378M 23180K accept 1 0:18 1.56% /usr/local/bin/php-cgi 15422 80 1 4 0 379M 24704K accept 1 0:23 1.37% /usr/local/bin/php-cgi 15423 80 1 4 0 379M 23368K accept 1 0:22 1.37% /usr/local/bin/php-cgi 15469 80 1 4 0 379M 24464K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15447 80 1 4 0 378M 23800K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15463 80 1 4 0 379M 25436K sbwait 1 0:19 1.37% /usr/local/bin/php-cgi 15474 80 1 4 0 379M 24772K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15472 80 1 4 0 379M 24536K sbwait 1 0:19 1.37% /usr/local/bin/php-cgi 15477 80 1 4 0 379M 25240K accept 0 0:19 1.37% /usr/local/bin/php-cgi 15476 80 1 4 0 378M 22972K sbwait 1 0:19 1.37% /usr/local/bin/php-cgi 15467 80 1 4 0 378M 23168K accept 1 0:19 1.37% /usr/local/bin/php-cgi 15480 80 1 4 0 378M 23488K sbwait 0 0:18 1.37% /usr/local/bin/php-cgi 15493 80 1 4 0 378M 24876K accept 1 0:18 1.37% /usr/local/bin/php-cgi ------------D11701C226D64ECE Content-Type: TEXT/PLAIN; name="dmesg.boot" Content-transfer-encoding: 8bit Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2008 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.0-STABLE #2: Tue Mar 18 16:16:43 CET 2008 danger@ha-web1.hockeyarena.net:/usr/obj/usr/src/sys/ha-web1 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2799.98-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 4253347840 (4056 MB) avail memory = 4099985408 (3910 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddf00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pci2: on pcib2 atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 em0: port 0xe800-0xe83f mem 0xfebe0000-0xfebfffff,0xfebc0000-0xfebdffff irq 20 at device 2.0 on pci3 em0: Ethernet address: 00:1b:21:10:f7:d5 em0: [FILTER] em1: port 0xe400-0xe43f mem 0xfeb80000-0xfeb9ffff,0xfeb60000-0xfeb7ffff irq 22 at device 5.0 on pci3 em1: Ethernet address: 00:1b:21:10:f2:27 em1: [FILTER] acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xcd800-0xce7ff,0xce800-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad4: 381554MB at ata2-master UDMA33 ad6: 381554MB at ata3-master UDMA33 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/usr launched (2/2). GEOM_MIRROR: Device mirror/data launched (2/2). Trying to mount root from ufs:/dev/mirror/root ------------D11701C226D64ECE-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 09:52:54 2008 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 153C21065672; Wed, 19 Mar 2008 09:52:54 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from aa002msb.fastweb.it (aa002msb.fastweb.it [85.18.95.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8A0FA8FC14; Wed, 19 Mar 2008 09:52:53 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.logital.it (89.97.230.176) by aa002msb.fastweb.it (8.0.013.5) id 47CFF4A801A570B5; Wed, 19 Mar 2008 10:41:18 +0100 Received: from [10.143.87.234] (89-97-230-139.ip19.fastwebnet.it [89.97.230.139]) (authenticated bits=0) by mail.logital.it (8.14.2/8.14.2) with ESMTP id m2J9eed1026410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 10:40:51 +0100 (CET) (envelope-from aturetta@commit.it) Message-ID: <47E0DF92.6010108@commit.it> Date: Wed, 19 Mar 2008 10:40:34 +0100 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Kris Kennaway References: <20080318205455.E23824500F@ptavv.es.net> <47E02E64.1090102@FreeBSD.org> In-Reply-To: <47E02E64.1090102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on mail.logital.it X-Virus-Status: Clean Cc: Marko Lerota , freebsd-stable@FreeBSD.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 09:52:54 -0000 Kris Kennaway wrote: > Kevin Oberman wrote: > >> Or, is the system failing to retrieve the packages and failing over to >> building the ports? This would take a long time! >> >> I always tee the output of portupgrade to a file so, if it dies in the >> middle, it's pretty easy to pick up where it left off and not re-build >> everything twice. > > Yes, also I am pretty sure that if you rerun portupgrade -faP a second > time it will reuse the cached packages it downloaded last time, if they > are not out of date. This may be true if you have created the /usr/ports/packages folder (which doesn't exist by default) Anyway, if the packages are not found, they will be built from sources. In this case adding -p will save the packages for the next run (so portupgrade -faPp). Angelo. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 10:47:11 2008 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 48698106566C for ; Wed, 19 Mar 2008 10:47:11 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A2B348FC12 for ; Wed, 19 Mar 2008 10:47:10 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2JAl8AJ070947; Wed, 19 Mar 2008 11:47:08 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2JAl7YL070946; Wed, 19 Mar 2008 11:47:07 +0100 (CET) (envelope-from olli) Date: Wed, 19 Mar 2008 11:47:07 +0100 (CET) Message-Id: <200803191047.m2JAl7YL070946@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, mlerota@iskon.hr In-Reply-To: <867igo3cih.fsf@zid.claresco.hr> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 19 Mar 2008 11:47:08 +0100 (CET) Cc: Subject: Re: Upgrading to 7.0 - stupid requirements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, mlerota@iskon.hr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 10:47:11 -0000 Hello Marko, I'm very sorry that you have trouble updating your FreeBSD installation, but there are very good technical reasons to update your packages, as others have already explained in detail (i.e. library conflicts). When I updated my home workstation from FreeBSD 6 to 7, I used the opportunity to clean up my installed packages, which was long overdue anyway. First I saved the output from "pkg_info" in a file. Then I edited it and removed everything that I don't need. There was lots of superfluous crap in it, like ports that I installed once out of curiosity but never continued to use them, and ports that were installed as a dependency once but aren't required anymore because the dependent software is long gone. Then I did "pkg_delete \*", checked for left-overs in /usr/local because not everything was removed cleanly, and then installed the ports from my text file again. I chose to compile from ports instead of installing precompiled packages because the machine is fairly fast (if you have a slow machine, installing packages will be much faster, of course). It certainly went a lot quicker than if I had blindly updated all ports without cleaning up. And now all of my installed packages are guaranteed to be fresh and up to date, and I only have the stuff on my harddisk that I really need. Really, such situations where you should update all of your packages is the best opportunity to clean up the mess that has accumulated on your disk in a long time. I recommend that everyone considers doing that, too, instead of blindly running portupgrade. Of course, the latter would work, too, but it takes longer and will rather add to the mess instead of cleaning it. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 11:48:28 2008 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 DE241106564A for ; Wed, 19 Mar 2008 11:48:28 +0000 (UTC) (envelope-from db@danielbond.org) Received: from mail.nsn.no (mailtwo.nsn.no [62.89.38.161]) by mx1.freebsd.org (Postfix) with SMTP id 3CA3E8FC13 for ; Wed, 19 Mar 2008 11:48:27 +0000 (UTC) (envelope-from db@danielbond.org) Received: (qmail 11128 invoked by uid 0); 19 Mar 2008 11:48:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (85.95.44.187) by mail.nsn.no with SMTP; 19 Mar 2008 11:48:25 -0000 Message-ID: <47E0FD88.4080207@danielbond.org> Date: Wed, 19 Mar 2008 12:48:24 +0100 From: Daniel Bond User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dmitriy Kirhlarov References: <47DE9638.6080609@danielbond.org> <47DF8F10.8080200@higis.ru> In-Reply-To: <47DF8F10.8080200@higis.ru> X-Enigmail-Version: 0.95.6 OpenPGP: id=1A8DD04A; url=http://web.danielbond.org/pgp/danielbond-pubkey.asc Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: ohartman@zedat.fu-berlin.de, freebsd-stable@freebsd.org, Valerio Daelli Subject: Re: [Working fix] Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 19 Mar 2008 11:48:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Dmitriy Kirhlarov wrote: | Hi! | | Daniel Bond wrote: | |> I'm pretty sure my ldap.conf and nsswitch.conf are OK, but here they are |> anyway: |> |> |> /usr/local/etc/nss_ldap.conf -> openldap/ldap.conf |> /usr/local/etc/ldap.conf -> openldap/ldap.conf | | I'm not sure is it correct. | etc/ldap.conf and etc/openldap/ldap.conf -- different files for | different purposes. | etc/nss_ldap.conf -> etc/ldap.conf -- it's correct. | The ldap.conf file is only used for nss_ldap and pam_ldap, so I don't suppose it really matters where the config-file resides. |> port 389 |> ldap_version 3 |> bind_policy soft | ^^^^^^^^^^^^^^^^^^ | | Try replace to | bind_policy hard | | Developers doesn't like "soft". I don't know why, but it periodically | it's broken in new versions nss_ldap (2 time for last 3 years AFAIR). | I'm not sure about current status. It must be tested. | You are absolutely correct, when I change *bind_policy* to *hard*, the problem goes away, nss_ldap stops whining about contacting server in /var/log/auth.log. SSH with pubkey-exchange or password authentication also works with bind_policy hard. Allthough it would be nice to have "bind_policy soft" working properly (I'm still interested in fixing this if I can manage to track it down), this is a sollution I'm quite happy with, and seems to work well. Thanks! | Also try | | echo "debug 9" >> /usr/local/etc/ldap.conf | | For details see | slapd.conf(5) about loglevel | | WBR. | Dmitriy | _______________________________________________ | 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" Cheers and happy easter, Daniel Bond, Network Solutions Norway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4P2IUR3pKhqN0EoRAoWdAJoDN3unZP4doZ/B1QbdgJw2gwbUmgCeOw49 hf6DTOvORC6md3jeMy6Qa6c= =K/Vc -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 12:24:15 2008 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 48588106566B for ; Wed, 19 Mar 2008 12:24:15 +0000 (UTC) (envelope-from dimma@higis.ru) Received: from mail.higis.ru (mail.higis.ru [213.147.37.35]) by mx1.freebsd.org (Postfix) with ESMTP id EF15D8FC13 for ; Wed, 19 Mar 2008 12:24:14 +0000 (UTC) (envelope-from dimma@higis.ru) Received: from [87.242.97.68] (port=50302 helo=dimma.masterhost.ru) by mail.higis.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JbxL3-000ORi-5A; Wed, 19 Mar 2008 15:24:13 +0300 Message-ID: <47E105EC.3080005@higis.ru> Date: Wed, 19 Mar 2008 15:24:12 +0300 From: Dmitriy Kirhlarov User-Agent: Thunderbird 2.0.0.4 (X11/20070621) MIME-Version: 1.0 To: Daniel Bond References: <47DE9638.6080609@danielbond.org> <47DF8F10.8080200@higis.ru> <47E0FD88.4080207@danielbond.org> In-Reply-To: <47E0FD88.4080207@danielbond.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, ohartman@zedat.fu-berlin.de, Valerio Daelli Subject: Re: [Working fix] Problems combining nss_ldap/pam_ldap with pam_mkhomedir in FreeBSD 7.0 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, 19 Mar 2008 12:24:15 -0000 Daniel Bond wrote: > |> /usr/local/etc/nss_ldap.conf -> openldap/ldap.conf > |> /usr/local/etc/ldap.conf -> openldap/ldap.conf > | > | I'm not sure is it correct. > | etc/ldap.conf and etc/openldap/ldap.conf -- different files for > | different purposes. > | etc/nss_ldap.conf -> etc/ldap.conf -- it's correct. > | > > The ldap.conf file is only used for nss_ldap and pam_ldap, so I don't > suppose it really matters where the config-file resides. etc/ldap.conf can be used by sudo, for example. etc/openldap/ldap.conf -- library config. > You are absolutely correct, when I change *bind_policy* to *hard*, the > problem goes away, nss_ldap stops whining about contacting server in > /var/log/auth.log. SSH with pubkey-exchange or password authentication > also works with bind_policy hard. Ok. Next. I'm sorry, but this solution little dangerous. When your ldap server unreachable, nss_ldap trying to connect again and again and doesn't switched to next method, described in /etc/nsswitch.conf. For example, if your computer must get IP over dhcpd, OS need uid for dhclient and ask it from nss_ldap, but nss_ldap can't connect to ldap server, because computer doesn't have IP address. When you are using bind_policy hard, you also need tune bind_timelimit and idle_timelimit in ldap.conf and use "files [Status=Action] ldap" in /etc/nsswitch.conf, where Status and Action must be choosen. > Allthough it would be nice to have "bind_policy soft" working properly Yes. It's realy fine option, but I don't sure about source of problem (OS version or nss_ldap) and doesn't know, how to debug this issue. WBR. Dmitriy From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 12:46:09 2008 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 96A9E106564A for ; Wed, 19 Mar 2008 12:46:09 +0000 (UTC) (envelope-from michael.grant@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDF28FC32 for ; Wed, 19 Mar 2008 12:46:09 +0000 (UTC) (envelope-from michael.grant@gmail.com) Received: by rn-out-0910.google.com with SMTP id e11so247487rng.7 for ; Wed, 19 Mar 2008 05:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=GYIbfwepPhTuSYukkPlKJV+rMWEN1/VtXxWNMOIxd10=; b=pC9FZsnZ/hbpZZxPgseasLyoLuuQNvXtqzDzBCNMVJpJhROHm7RLgsVdt40qmxVk2AxGkCPXaxafSki39TRMIRhI1hmSs4qMyhp6+4rujqWJCByZVgQA68FrRU0nsW0Ywm21cDJQVoyuhlFLXQhMPToxqW5dqPoMSq/uymO6cdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LJdjeltuCMS+opOs2XSDA2IDbq2OQq1Ce5K0Csw7OZ00DQACqGDSysR3ZhkoUHLmB32dxiZTxaLZcwsrtJMZA9Lq86Oqph/eZeKgDJpQdktgA5nKpgGRIAGizvi4MuoKlFvzdF3S8CQBagWDwCLQDy4AfYpGyF6zL8xmY8gczNo= Received: by 10.143.40.18 with SMTP id s18mr116551wfj.156.1205930767987; Wed, 19 Mar 2008 05:46:07 -0700 (PDT) Received: by 10.142.169.6 with HTTP; Wed, 19 Mar 2008 05:46:07 -0700 (PDT) Message-ID: <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> Date: Wed, 19 Mar 2008 13:46:07 +0100 From: "Michael Grant" Sender: michael.grant@gmail.com To: freebsd-stable@freebsd.org In-Reply-To: <200803191047.m2JAl7YL070946@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <867igo3cih.fsf@zid.claresco.hr> <200803191047.m2JAl7YL070946@lurza.secnetix.de> X-Google-Sender-Auth: fbd865767a63c82e Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 12:46:09 -0000 My server is live and serving customers. I can't afford to take the box down for a whole day while I upgrade ports. Is there any intelligent way to do this? For example, could I do everything on a second disk while running the live system on the first disk? For example using a chroot so it thinks it's For example, might this work? 1) upgrade system in the canonical way: # make buildworld # make buildkernel # make installkernel # reboot # mergemaster -p # make installworld # mergemaster # reboot 2) make sure misc/compat6x is installed 3) on a second disk or in a directory somewhere like /new a) nullfs mount read-only all the things one needs inside a chroot to work except /usr/local b) create a writable /usr/local, /usr/X11R6, /compat/linux and /var/db in the chroot 4) then for each package installed, install it within the chroot 5) when all that's done, drop into single-user mode and move /usr/local, /usr/X11R6, /compat/linux, and /var/db/pkg to the real system (saving the old ones) 6) reboot Warning, I have never tried this. -Mike On Wed, Mar 19, 2008 at 11:47 AM, Oliver Fromme wr= ote: > Hello Marko, > > I'm very sorry that you have trouble updating your FreeBSD > installation, but there are very good technical reasons to > update your packages, as others have already explained in > detail (i.e. library conflicts). > > When I updated my home workstation from FreeBSD 6 to 7, > I used the opportunity to clean up my installed packages, > which was long overdue anyway. > > First I saved the output from "pkg_info" in a file. Then > I edited it and removed everything that I don't need. > There was lots of superfluous crap in it, like ports that > I installed once out of curiosity but never continued to > use them, and ports that were installed as a dependency > once but aren't required anymore because the dependent > software is long gone. > > Then I did "pkg_delete \*", checked for left-overs in > /usr/local because not everything was removed cleanly, > and then installed the ports from my text file again. > I chose to compile from ports instead of installing > precompiled packages because the machine is fairly fast > (if you have a slow machine, installing packages will > be much faster, of course). > > It certainly went a lot quicker than if I had blindly > updated all ports without cleaning up. And now all of > my installed packages are guaranteed to be fresh and > up to date, and I only have the stuff on my harddisk > that I really need. > > Really, such situations where you should update all of > your packages is the best opportunity to clean up the > mess that has accumulated on your disk in a long time. > I recommend that everyone considers doing that, too, > instead of blindly running portupgrade. Of course, > the latter would work, too, but it takes longer and > will rather add to the mess instead of cleaning it. ;-) > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M= . > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehru= ng: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M= =FCn- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Ge= bhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bs= d > > Python is executable pseudocode. Perl is executable line noise. > > > _______________________________________________ > 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 Mar 19 13:34:01 2008 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 7D6811065670 for ; Wed, 19 Mar 2008 13:34:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC368FC12 for ; Wed, 19 Mar 2008 13:34:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 9494A1A4D7C; Wed, 19 Mar 2008 06:32:38 -0700 (PDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 19 Mar 2008 09:28:28 -0400 User-Agent: KMail/1.9.7 References: <000e01c8885f$d78bc070$26714dd1@syix.com> <47DECC95.2030608@moneybookers.com> <200803182309.46931.danny@ricin.com> In-Reply-To: <200803182309.46931.danny@ricin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803190928.29081.jhb@freebsd.org> Cc: Danny Pansters Subject: Re: +rtfree: 0xffffff0003635780 has 1 refs 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, 19 Mar 2008 13:34:01 -0000 On Tuesday 18 March 2008 06:09:46 pm Danny Pansters wrote: > On Monday 17 March 2008 20:55:01 Stefan Lambrev wrote: > > Greetings Dave, > > > > Dave Overton wrote: > > > I am new to the AMD64 stable branch, so forgive me if this has been > > > beat to death, but I can't find why this message keeps occurring over > > > and over all day. FreeBSD 7.0 Stable on AMD x2. It works (or seems > > > to) fine. > > > > > > +rtfree: 0xffffff0003635780 has 1 refs > > > > check google for rtfree() used when RTFREE() needed .. or something like > > this :) > > Those messages are annoying but harmless. > > Harmless perhaps, but it still should be fixed, so if you don't see any > similar PR already I'd suggest sending one. > > Has to do with certain variables being of one type but used as if it were > another (e.g. int vs long) which on 64bit platforms as a band-aid > gets "MSB-filled" with 0xf's to the proper size. So such warning pretty > much means "fix your code". No. The value printed is a pointer and kernel pointers on amd64 are in the upper range of the address space. The warning above has to do with code that calls rtfree() vs. the RTFREE() macro. The macro inlines the the common case (refs > 1) so in theory is cheaper than always doing a function call. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 13:36:30 2008 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 B6B1D106567B for ; Wed, 19 Mar 2008 13:36:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id A794F8FC16 for ; Wed, 19 Mar 2008 13:36:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 8F3E81CC060; Wed, 19 Mar 2008 06:36:30 -0700 (PDT) Date: Wed, 19 Mar 2008 06:36:30 -0700 From: Jeremy Chadwick To: Michael Grant Message-ID: <20080319133630.GA14376@eos.sc1.parodius.com> References: <867igo3cih.fsf@zid.claresco.hr> <200803191047.m2JAl7YL070946@lurza.secnetix.de> <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 13:36:30 -0000 On Wed, Mar 19, 2008 at 01:46:07PM +0100, Michael Grant wrote: > My server is live and serving customers. I can't afford to take the > box down for a whole day while I upgrade ports. Is there any > intelligent way to do this? The ways people have given you are proper *and* intelligent. I think the piece of information you're not understanding (or haven't been given?) is that library semantics change. That doesn't just mean library version numbers -- it means actual API functionality changes. > For example, could I do everything on a second disk while running the > live system on the first disk? For example using a chroot so it > thinks it's > > For example, might this work? > > 1) upgrade system in the canonical way: > # make buildworld > # make buildkernel > # make installkernel > # reboot > # mergemaster -p > # make installworld > # mergemaster > # reboot Assuming after "reboot" you include boot into single user: yep, correct. Follow the procedure documented in /usr/src/Makefile to a tee. Do not deviate from it unless you know *exactly* the risks of doing so. :-) By the way, all of the above guarantees downtime. You seem to be of the "I must achieve Five Nines" mentality, so I'll point you to why Five Nines is absurd: http://en.wikipedia.org/wiki/Myth_of_the_nines > 2) make sure misc/compat6x is installed You're asking for trouble right here. I've discussed in a previous thread (if you want me to dig it up I can) the dangers of using the compatXx packages. You can: * End up with dual libraries in your ld.so path, which can result in functions of the same name being loaded, which is a problem because... * Function semantics/API differences exist between RELENG_7 and RELENG_6, 6 and 5, 5 and 4, 4 and 3 -- but function names remain the same. * Library innards change. Best example? libkvm. These are so major that an entries goes into /usr/src/UPDATING when the semantics change. People who don't follow the proper upgrade procedure get amusing results: "top doesn't work, it spits out some weird error!" "why is ps broken?!?" etc. * "Library nightmare" syndrome, which is the UNIX equivalent of Windows' "DLL Hell". Some program on the machine attempts to link to a library called "libapemans.so.4", and you have two versions of it: one for 6, and one for 7. Uh oh! How do you avoid these problems? You use software that you have the source for, and rebuild that software from the source. You then guarantee (assuming compatXx isn't installed) that the software links to a proper library, works with proper API functionality (or else it won't compile/link properly), and you retain a clean library tree. In the case of packages, they're also OK. Just be sure to use ones for the OS release you're using; don't go pkg_add'ing packages from RELENG_5 on your RELENG_7 box, for example. :-) Remember: you have the source. Do you have programs from commercial vendors who do not give you source, which relies upon RELENG_6? If so, you should consider *not* migrating from RELENG_6, and instead getting your vendor to build their software on RELENG_7! Work with them, help them, test with them. > 3) on a second disk or in a directory somewhere like /new > a) nullfs mount read-only all the things one needs inside a chroot to > work except /usr/local > b) create a writable /usr/local, /usr/X11R6, /compat/linux and /var/db > in the chroot > > 4) then for each package installed, install it within the chroot I don't see how this is going to work. You would need to copy a TON of files from /usr/lib, /libexec, /usr/libexec, and other places into your chroot tree before anything will work. You'll also have to use chflags to deal with files that're schg. Additionally, if you're installing **packages**, why are you bothering with the chroot aspect? This should be a VERY quick task -- no compiling needed, since they're all binary. It WILL NOT take an entire day. I'd say 30 minutes -- tops. All that said... I'm a hosting provider myself, not just of websites, but of servers and of rack space as well. I've done it since 1993, using Linux from 1993 to 1997. We have users who are lax ("oh, the server was down for 2 hours? No biggie"), and those who are so incredibly anal that I consider terminating them ("The site was offline for 15 seconds when you reloaded Apache, why?!"). We also have commercial customers who demand *prior* notice of when we do things, and trust our ability/judgement. In the case of all clientel, we tell them when there's going to be downtime (unless otherwise unexpected), and give them a general estimate of the downtime when it's going to happen. They have come to accept that, regardless of how long. Customers are actually not too bad as long as you communicate with them honestly and openly. We have multiple servers. Some run RELENG_7, others RELENG_6. We've gone through the pain of RELENG_3 --> 4 --> 5 --> 6 --> 7 over the years, and definitely found what's most effective. We reinstall the OS, because that's what works best -- and because the "magical major revision upgrade path" is chaotic, has a history of leaving random crap laying around on your filesystem, and (any good SA will know what I mean by this) does not give the "good feeling" of a clean system. So how did we upgrade from RELENG_4 to RELENG_6 (we skipped 5) on our main webserver? It was fairly simple: We had a RELENG_6 server built, and compiled all the same ports we had on the RELENG_4 box. I spent a week or so making sure the machine had a working Apache server, and did my best to thoroughly test it -- including asking some users "would you mind if we moved your site over to a beta/test box to make sure things worked?" Things did work. I then announced downtime to all the clientel, saying "this is a major upgrade, and will probably take a few hours guaranteed". I started moving home directories over using dump/restore, updated DNS records, and did numerous other things which I can't even remember. Entire downtime was about an hour, most of which was due to the amount of data we had to copy over. If we used NFS, this would've been much easier. There was one mistake which happened (some incorrect firewall rules, the result of our ipfw --> pf migration), and I fixed it when someone reported it ("I can't FTP..."). We'll have to do the same thing when going from 6 to 7. I have a spare box ready to go for said migration path. My advice to you is get another box. Prep it for the migration prior, then move things over. It's the logical, intelligent, and professional way of doing upgrades in any production environment. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 14:32:54 2008 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 C46AA106566C for ; Wed, 19 Mar 2008 14:32:54 +0000 (UTC) (envelope-from mkushnir@lohika.com) Received: from dekker.lohika.com (lohika-171.rns.lviv.ua [217.9.0.171]) by mx1.freebsd.org (Postfix) with ESMTP id 12B5E8FC13 for ; Wed, 19 Mar 2008 14:32:53 +0000 (UTC) (envelope-from mkushnir@lohika.com) Received: from medium.ua.lohika.com (videolib.ua.lohika.com [172.22.100.19]) by dekker.lohika.com (8.14.2/8.14.2) with ESMTP id m2JEE1fL034036; Wed, 19 Mar 2008 14:14:01 GMT (envelope-from mkushnir@lohika.com) Received: from emkushnir.ua.lohika.com ([172.22.60.70]) (authenticated bits=0) by medium.ua.lohika.com (8.14.2/8.14.2) with ESMTP id m2JECDCt070491; Wed, 19 Mar 2008 16:12:14 +0200 (EET) (envelope-from mkushnir@lohika.com) Message-ID: <47E13A9C.9010401@lohika.com> Date: Wed, 19 Mar 2008 16:09:00 +0000 From: Markiyan Kushnir User-Agent: Thunderbird 2.0.0.9 (X11/20080311) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, mlerota@iskon.hr References: <200803191047.m2JAl7YL070946@lurza.secnetix.de> In-Reply-To: <200803191047.m2JAl7YL070946@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/6305/Wed Mar 19 07:32:53 2008 on dekker.lohika.com X-Virus-Scanned: ClamAV 0.92/6303/Wed Mar 19 07:25:55 2008 on medium.ua.lohika.com X-Virus-Status: Clean Cc: Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 14:32:54 -0000 It's amazing -- I also did my recent 6.3->7.0 exactly this way. Running it as a desktop, WindowMaker, some of gnu apps. kde is at hand mostly for a couple of applications, but it works ok either. My case is much simpler, but I feel that it's worth of considering alternatives to portupgrade. I learned much from using portupgrade. Thanks, Markiyan Oliver Fromme wrote: > Hello Marko, > > I'm very sorry that you have trouble updating your FreeBSD > installation, but there are very good technical reasons to > update your packages, as others have already explained in > detail (i.e. library conflicts). > > When I updated my home workstation from FreeBSD 6 to 7, > I used the opportunity to clean up my installed packages, > which was long overdue anyway. > > First I saved the output from "pkg_info" in a file. Then > I edited it and removed everything that I don't need. > There was lots of superfluous crap in it, like ports that > I installed once out of curiosity but never continued to > use them, and ports that were installed as a dependency > once but aren't required anymore because the dependent > software is long gone. > > Then I did "pkg_delete \*", checked for left-overs in > /usr/local because not everything was removed cleanly, > and then installed the ports from my text file again. > I chose to compile from ports instead of installing > precompiled packages because the machine is fairly fast > (if you have a slow machine, installing packages will > be much faster, of course). > > It certainly went a lot quicker than if I had blindly > updated all ports without cleaning up. And now all of > my installed packages are guaranteed to be fresh and > up to date, and I only have the stuff on my harddisk > that I really need. > > Really, such situations where you should update all of > your packages is the best opportunity to clean up the > mess that has accumulated on your disk in a long time. > I recommend that everyone considers doing that, too, > instead of blindly running portupgrade. Of course, > the latter would work, too, but it takes longer and > will rather add to the mess instead of cleaning it. ;-) > > Best regards > Oliver > From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 16:41:28 2008 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 9AC86106568C for ; Wed, 19 Mar 2008 16:41:28 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (thingy.kcilink.com [74.92.149.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7656E8FC20 for ; Wed, 19 Mar 2008 16:41:28 +0000 (UTC) (envelope-from vivek@khera.org) Received: from host-121.int.kcilink.com (host-121.int.kcilink.com [192.168.7.121]) by yertle.kcilink.com (Postfix) with ESMTP id ED9658A0AD for ; Wed, 19 Mar 2008 12:41:21 -0400 (EDT) Message-Id: From: Vivek Khera To: FreeBSD Stable In-Reply-To: <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 12:41:21 -0400 References: <867igo3cih.fsf@zid.claresco.hr> <200803191047.m2JAl7YL070946@lurza.secnetix.de> <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 16:41:28 -0000 On Mar 19, 2008, at 8:46 AM, Michael Grant wrote: > My server is live and serving customers. I can't afford to take the > box down for a whole day while I upgrade ports. Is there any > intelligent way to do this? Here's what you do: 1) take one server at a time down from the load balancer/worker pool 2) upgrade it 3) put it back in service 4) go to step 1 until all servers are updated. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 16:58:27 2008 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 1E2951065670 for ; Wed, 19 Mar 2008 16:58:27 +0000 (UTC) (envelope-from danny@ricin.com) Received: from smtpq2.tilbu1.nb.home.nl (smtpq2.tilbu1.nb.home.nl [213.51.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id ABDAB8FC2A for ; Wed, 19 Mar 2008 16:58:26 +0000 (UTC) (envelope-from danny@ricin.com) Received: from [213.51.146.188] (port=48815 helo=smtp3.tilbu1.nb.home.nl) by smtpq2.tilbu1.nb.home.nl with esmtp (Exim 4.60) (envelope-from ) id 1Jc1cP-0004DD-IH for freebsd-stable@freebsd.org; Wed, 19 Mar 2008 17:58:25 +0100 Received: from [84.27.119.97] (port=51298 helo=desktop.homenet) by smtp3.tilbu1.nb.home.nl with smtp (Exim 4.60) (envelope-from ) id 1Jc1cP-0005TF-3K for freebsd-stable@freebsd.org; Wed, 19 Mar 2008 17:58:25 +0100 Received: by desktop.homenet (sSMTP sendmail emulation); Wed, 19 Mar 2008 17:57:09 +0100 From: "Danny Pansters" To: freebsd-stable@freebsd.org Date: Wed, 19 Mar 2008 17:57:09 +0100 User-Agent: KMail/1.9.7 References: <000e01c8885f$d78bc070$26714dd1@syix.com> <200803182309.46931.danny@ricin.com> <200803190928.29081.jhb@freebsd.org> In-Reply-To: <200803190928.29081.jhb@freebsd.org> X-Face: (Zs+'ncTcchkOX|~t6{?Iii=O!G#WEK!+OD0|-F=i%1pvP5V_Sz4PaJC8o)=?utf-8?q?MiSnH/JMJFy=0A=09oBN-My?=, v":S7, (=?utf-8?q?mmkPm=27U=7BMgT+eM=2EBd=5Cp/P!dr=5DhOTXqpse21O!=25Ct=60SE=2EOodq?= =?utf-8?q?=5Dry=5E=23kU=5E=0A=09-?=GT.[8D}i$6P>=" =?utf-8?q?=23=0A=09*J+4d=7E?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803191757.09256.danny@ricin.com> X-Spam-Score: 0.0 (/) Subject: Re: +rtfree: 0xffffff0003635780 has 1 refs 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, 19 Mar 2008 16:58:27 -0000 On Wednesday 19 March 2008 14:28:28 John Baldwin wrote: > On Tuesday 18 March 2008 06:09:46 pm Danny Pansters wrote: > > On Monday 17 March 2008 20:55:01 Stefan Lambrev wrote: > > > Greetings Dave, > > > > > > Dave Overton wrote: > > > > I am new to the AMD64 stable branch, so forgive me if this has been > > > > beat to death, but I can't find why this message keeps occurring over > > > > and over all day. FreeBSD 7.0 Stable on AMD x2. It works (or seems > > > > to) fine. > > > > > > > > +rtfree: 0xffffff0003635780 has 1 refs > > > > > > check google for rtfree() used when RTFREE() needed .. or something > > > like this :) > > > Those messages are annoying but harmless. > > > > Harmless perhaps, but it still should be fixed, so if you don't see any > > similar PR already I'd suggest sending one. > > > > Has to do with certain variables being of one type but used as if it were > > another (e.g. int vs long) which on 64bit platforms as a band-aid > > gets "MSB-filled" with 0xf's to the proper size. So such warning pretty > > much means "fix your code". > > No. The value printed is a pointer and kernel pointers on amd64 are in the > upper range of the address space. The warning above has to do with code > that calls rtfree() vs. the RTFREE() macro. The macro inlines the the > common case (refs > 1) so in theory is cheaper than always doing a function > call. I stand corrected! Dan From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 17:33:00 2008 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 72CBC1065676 for ; Wed, 19 Mar 2008 17:33:00 +0000 (UTC) (envelope-from vincent@netaktiv.com) Received: from aragon.netaktiv.com (aragon.netaktiv.com [62.212.103.139]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5648FC2F for ; Wed, 19 Mar 2008 17:33:00 +0000 (UTC) (envelope-from vincent@netaktiv.com) Received: from [172.21.0.42] (unknown [172.21.0.42]) by aragon.netaktiv.com (Postfix) with ESMTP id 114782ED5C; Wed, 19 Mar 2008 18:03:32 +0100 (CET) From: Vincent Mialon To: freebsd-stable@freebsd.org Date: Wed, 19 Mar 2008 18:03:31 +0100 User-Agent: KMail/1.9.9 References: <867igo3cih.fsf@zid.claresco.hr> <62b856460803190546t4abfcb9fu7d3410646d81b656@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803191803.31872.vincent@netaktiv.com> Cc: Vivek Khera Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 17:33:00 -0000 Le Wednesday 19 March 2008 17:41:21 Vivek Khera, vous avez =E9crit=A0: > On Mar 19, 2008, at 8:46 AM, Michael Grant wrote: > > My server is live and serving customers. I can't afford to take the > > box down for a whole day while I upgrade ports. Is there any > > intelligent way to do this? > > Here's what you do: > > 1) take one server at a time down from the load balancer/worker pool > 2) upgrade it > 3) put it back in service > 4) go to step 1 until all servers are updated. Why not installing FreeBSD 7 on a spare server or a workstation ? You can=20 build your own packages, rsync your confs and test.=20 When everything work, delete all packages on the old server. Make a=20 freebsd-upgrade install. Install all your previously builded packages and p= ut=20 your confs back. The down time should not be too long I gess ? From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 17:53:41 2008 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 48EB5106566B for ; Wed, 19 Mar 2008 17:53:41 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BCEF98FC17 for ; Wed, 19 Mar 2008 17:53:40 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2JHrd99092584; Wed, 19 Mar 2008 18:53:39 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2JHraI5092556; Wed, 19 Mar 2008 18:53:36 +0100 (CET) (envelope-from olli) Date: Wed, 19 Mar 2008 18:53:36 +0100 (CET) Message-Id: <200803191753.m2JHraI5092556@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, root@ha-web1.hockeyarena.net In-Reply-To: <669936444.20080319100148@rulez.sk> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 19 Mar 2008 18:53:39 +0100 (CET) Cc: Subject: Re: Weird system cpu usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, root@ha-web1.hockeyarena.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 17:53:41 -0000 Charlie Root wrote: > [...] It's preferable to send mail as a real user, not as root, for various reasons. > I have to report, that I have a very strange cpu usage by system (as > the `top' reports). You haven't mentioned what exactly you think is strange in your top(1) output. I think it looks pretty normal under the given circumstances. > root@[ha-web1 ~]# vmstat -i > interrupt total rate > irq1: atkbd0 12 0 > irq16: ohci0 1 0 > irq17: ohci1 ohci3 1 0 > irq18: ohci2 ohci4 1 0 > irq20: em0 86255835 1361 > irq22: em1 atapci0 18611379049 293795 Now that looks unusual indeed. Do you get that rate on irq22 right after boot, before the services have started? It looks like either hardware or driver problems. Do you have polling enabled on em1? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 18:06:30 2008 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 61960106566B for ; Wed, 19 Mar 2008 18:06:29 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 595998FC12 for ; Wed, 19 Mar 2008 18:06:29 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 481971CC060; Wed, 19 Mar 2008 11:06:29 -0700 (PDT) Date: Wed, 19 Mar 2008 11:06:29 -0700 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.ORG, root@ha-web1.hockeyarena.net Message-ID: <20080319180629.GA29308@eos.sc1.parodius.com> References: <669936444.20080319100148@rulez.sk> <200803191753.m2JHraI5092556@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803191753.m2JHraI5092556@lurza.secnetix.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: Weird system cpu usage 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, 19 Mar 2008 18:06:30 -0000 On Wed, Mar 19, 2008 at 06:53:36PM +0100, Oliver Fromme wrote: > Charlie Root wrote: > > root@[ha-web1 ~]# vmstat -i > > interrupt total rate > > irq1: atkbd0 12 0 > > irq16: ohci0 1 0 > > irq17: ohci1 ohci3 1 0 > > irq18: ohci2 ohci4 1 0 > > irq20: em0 86255835 1361 > > irq22: em1 atapci0 18611379049 293795 > > Now that looks unusual indeed. Do you get that rate > on irq22 right after boot, before the services have > started? It looks like either hardware or driver > problems. Do you have polling enabled on em1? Also, I believe there was a report from another user who saw similar issues with em(4), and found that disabling MSI fixed the storm in question. I believe you can disable MSI/MSIX by placing the following in /boot/loader.conf, then reboot: hw.pci.enable_msi="0" hw.pci.enable_msix="0" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 18:43:34 2008 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 02280106567B for ; Wed, 19 Mar 2008 18:43:34 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from zid.claresco.hr (zid.claresco.hr [85.114.42.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD2D8FC33 for ; Wed, 19 Mar 2008 18:43:32 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: (qmail 4447 invoked by uid 1001); 19 Mar 2008 19:43:25 +0100 To: Kris Kennaway Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <47E0249C.8030700@FreeBSD.org> (Kris Kennaway's message of "Tue, 18 Mar 2008 21:22:52 +0100") References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> Organization: *BSD Users - Fanatics Dept. From: Marko Lerota Date: Wed, 19 Mar 2008 19:43:25 +0100 Message-ID: <868x0ezh9u.fsf@zid.claresco.hr> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 18:43:34 -0000 Kris Kennaway writes: > Are you connected via a modem or something? 2-3 days to download some > packages cannot be right if you have a decent internet connection. No I have 5Mbps link. It's not the link issue. It's the compilation time from ports because there are only small portion of precompiled packages. And some of my apps need special switches like to tell PHP to build module for apache. I cant do that just from portupgrade -faP. If you use BSD system only for few apps like PHP/Apache/MySQL it would be easy. But if you have lots of stuff for desktop machine (gnome,xfce etc.) it's very painful, long, and waste of time. (I don't have x386 33MHz CPU) This thing should be solved. I liked the way that my OS have independance from ports. So no metter what I do with ports, my OS and his apps will work. And If I upgrade the OS I dont want to recompile ports for that. If this thing can be solved (I'm not programmer so I don't know) I can donate some amount of $ for development. I think that this would make lots of people happy. -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 19:32:43 2008 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 6C7441065671; Wed, 19 Mar 2008 19:32:43 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3538FC16; Wed, 19 Mar 2008 19:32:43 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 423841CC06A; Wed, 19 Mar 2008 12:32:43 -0700 (PDT) Date: Wed, 19 Mar 2008 12:32:43 -0700 From: Jeremy Chadwick To: Marko Lerota Message-ID: <20080319193243.GA30784@eos.sc1.parodius.com> References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868x0ezh9u.fsf@zid.claresco.hr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 19:32:43 -0000 On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote: > If you use BSD system only for few apps like PHP/Apache/MySQL it would > be easy. But if you have lots of stuff for desktop machine (gnome,xfce etc.) > it's very painful, long, and waste of time. (I don't have x386 33MHz CPU) > > This thing should be solved. I liked the way that my OS have independance > from ports. So no metter what I do with ports, my OS and his apps will work. > And If I upgrade the OS I dont want to recompile ports for that. > If this thing can be solved (I'm not programmer so I don't know) I can > donate some amount of $ for development. I think that this would make > lots of people happy. Am I to understand that you want prebuilt binary packages for PHP which encapsulate every possible combination of "make config" options? That's a bit unreasonable with how the ports framework is built. That's something like over a hundred prebuilt packages -- just for PHP. That said: I do understand what you're saying, and yes, I can see why you would want that. It does make sense, and it's reasonable. It's just hard to achieve. I don't think other mainstream OSes (e.g. Linux) offer this ability either, though. Am I wrong? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 19:46:54 2008 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 96BE0106566B for ; Wed, 19 Mar 2008 19:46:54 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) Received: from ironport2-out.pppoe.ca (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 300098FC21 for ; Wed, 19 Mar 2008 19:46:54 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAAsL4UdMCqa7/2dsb2JhbACLF59QBA X-IronPort-AV: E=Sophos;i="4.25,526,1199682000"; d="scan'208";a="16247586" Received: from mail.pppoe.ca ([65.39.192.132]) by ironport2-out.pppoe.ca with ESMTP; 19 Mar 2008 15:46:53 -0400 Received: from kevin ([76.10.166.187]) by mail.pppoe.ca (Internet Mail Server v1.0) with ASMTP id ZWN04253; Wed, 19 Mar 2008 15:46:53 -0400 From: "Kevin K" To: "'Jeremy Chadwick'" , "'Marko Lerota'" References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> <20080319193243.GA30784@eos.sc1.parodius.com> In-Reply-To: <20080319193243.GA30784@eos.sc1.parodius.com> Date: Wed, 19 Mar 2008 15:46:52 -0400 Message-ID: <000401c889f9$fab77c10$f0267430$@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: AciJ+BnuwnrSf6HwQRKceDzehuZHgQAAdF8g Content-Language: en-us Cc: 'Kris Kennaway' , freebsd-stable@freebsd.org Subject: RE: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 19:46:54 -0000 > That said: I do understand what you're saying, and yes, I can see why > you would want that. It does make sense, and it's reasonable. It's > just hard to achieve. I don't think other mainstream OSes (e.g. Linux) > offer this ability either, though. Am I wrong? Redhat's up2date/yum ? I'm not 100% certain though. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 19:47:18 2008 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 4F2971065700 for ; Wed, 19 Mar 2008 19:47:18 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 345048FC19 for ; Wed, 19 Mar 2008 19:47:18 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1D56B2651BB3; Wed, 19 Mar 2008 12:47:18 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 097312807D; Wed, 19 Mar 2008 12:47:18 -0700 (PDT) X-AuditID: 11807130-a98cebb0000008b8-a6-47e16dc5bce6 Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay11.apple.com (Apple SCV relay) with ESMTP id E8E8928042; Wed, 19 Mar 2008 12:47:17 -0700 (PDT) Message-Id: <9F019019-E23E-40B9-A070-7583C78DDE84@mac.com> From: Chuck Swiger To: Marko Lerota In-Reply-To: <868x0ezh9u.fsf@zid.claresco.hr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 12:47:17 -0700 References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: FreeBSD Stable List Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 19:47:18 -0000 On Mar 19, 2008, at 11:43 AM, Marko Lerota wrote: > This thing should be solved. I liked the way that my OS have > independance > from ports. So no metter what I do with ports, my OS and his apps > will work. > And If I upgrade the OS I dont want to recompile ports for that. The traditional mechanism for ensuring that a binary would continue to work after an OS upgrade is to statically link in any libraries used, which would prevent the problem of upgrading some shared library that normally would be dynamically loaded and thus inherit a mixture of dependencies. The main disadvantage of static linking is that you can't update a library to fix bugs or whatever without having to relink the program the way you could update a shared library; secondarily, dynamic linking can reduce the overall system memory requirements for running lots of processes which use common shared libraries. -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 20:22:09 2008 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 1F62710656BC for ; Wed, 19 Mar 2008 20:22:09 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id C8F5B8FC19 for ; Wed, 19 Mar 2008 20:22:08 +0000 (UTC) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 0FCCB10E5D2; Wed, 19 Mar 2008 20:50:16 +0100 (CET) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDz1ATUEAJFg; Wed, 19 Mar 2008 20:50:14 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id 78D6810E579; Wed, 19 Mar 2008 20:50:14 +0100 (CET) Date: Wed, 19 Mar 2008 20:51:27 +0100 From: Daniel Gerzo X-Mailer: The Bat! (v3.99.3) Professional X-Priority: 3 (Normal) Message-ID: <1075101608.20080319205127@rulez.sk> To: Oliver Fromme In-Reply-To: <200803191753.m2JHraI5092556@lurza.secnetix.de> References: <669936444.20080319100148@rulez.sk> <200803191753.m2JHraI5092556@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re[2]: Weird system cpu usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 20:22:09 -0000 Hello Oliver, Wednesday, March 19, 2008, 6:53:36 PM, you wrote: > Charlie Root wrote: >> [...] > It's preferable to send mail as a real user, not as root, > for various reasons. I know, I've just forgot to edit the headers, my apologies. >> I have to report, that I have a very strange cpu usage by system (as >> the `top' reports). > You haven't mentioned what exactly you think is strange > in your top(1) output. I think it looks pretty normal > under the given circumstances. What do you mean by "given" circumstances? I don't think that 50+% cpu usage by system is that normal. >> root@[ha-web1 ~]# vmstat -i >> interrupt total rate >> irq1: atkbd0 12 0 >> irq16: ohci0 1 0 >> irq17: ohci1 ohci3 1 0 >> irq18: ohci2 ohci4 1 0 >> irq20: em0 86255835 1361 >> irq22: em1 atapci0 18611379049 293795 > Now that looks unusual indeed. Do you get that rate > on irq22 right after boot, before the services have > started? It looks like either hardware or driver > problems. Do you have polling enabled on em1? No, the rate slowly increases after the system boots. Polling is disabled at the moment. -- Best regards, Daniel mailto:danger@rulez.sk From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 20:25:31 2008 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 0B2971065674 for ; Wed, 19 Mar 2008 20:25:31 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id BD21B8FC13 for ; Wed, 19 Mar 2008 20:25:30 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 50so566154wra.13 for ; Wed, 19 Mar 2008 13:25:30 -0700 (PDT) Received: by 10.141.15.19 with SMTP id s19mr467082rvi.75.1205958328962; Wed, 19 Mar 2008 13:25:28 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Wed, 19 Mar 2008 13:25:28 -0700 (PDT) Message-ID: <3dd203290803191325v6fd105fdqebdd693ffcb634f2@mail.gmail.com> Date: Wed, 19 Mar 2008 20:25:28 +0000 From: "Brad Pitney" To: "Kevin K" In-Reply-To: <000401c889f9$fab77c10$f0267430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> <20080319193243.GA30784@eos.sc1.parodius.com> <000401c889f9$fab77c10$f0267430$@com> Cc: Marko Lerota , Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 20:25:31 -0000 On Wed, Mar 19, 2008 at 7:46 PM, Kevin K wrote: > > That said: I do understand what you're saying, and yes, I can see why > > you would want that. It does make sense, and it's reasonable. It's > > just hard to achieve. I don't think other mainstream OSes (e.g. Linux) > > offer this ability either, though. Am I wrong? > > Redhat's up2date/yum ? I'm not 100% certain though. > OpenBSD's pkg_add has an -i option that allows options, their binary packages are build with various options, also they recommend using their binary packages as opposed to building your own. Although with FreeBSD having over 18000 ports, I don't see it as viable given constraints. some people are just ungrateful for what they already have, even if they have options. Marko, there is nothing stopping you from building binary packages on another machine with the options YOU want, some ports might not remember what it is was you specified, well there are work arounds, just remember /etc/make.conf is just like a Makefile so you could do something like this: .if ${.CURDIR:M*/ports} .if ${.CURDIR:M*/apache22} WITH_APR_FROM_PORTS= WITH_MPM=worker WITH_PGSQL= WITH_STATIC_SUPPORT= WITH_SQLITE= WITH_KQUEUE_SUPPORT= WITH_THREADS= .endif .endif by the way, it's a suggestion, nothing more. But Works For Me (TM). I would love to see something like the way pkgsrc handles options in ports: PKG_DEFAULT_OPTIONS = ssl pam kerberos acl ads ldap lang-en-GB gssapi kqueue sasl sqlite apr1 apache22 PKG_DEFAULT_OPTIONS += -debug -mysql -ruby-build-ri-db PKG_OPTIONS.sudo = -kerberos > > > > > > _______________________________________________ > 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" > -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 20:28:38 2008 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 5B18F1065674 for ; Wed, 19 Mar 2008 20:28:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BDCF08FC2E for ; Wed, 19 Mar 2008 20:28:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m2JKSZYl098817; Wed, 19 Mar 2008 21:28:36 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m2JKSZen098816; Wed, 19 Mar 2008 21:28:35 +0100 (CET) (envelope-from olli) Date: Wed, 19 Mar 2008 21:28:35 +0100 (CET) Message-Id: <200803192028.m2JKSZen098816@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, mlerota@iskon.hr In-Reply-To: <868x0ezh9u.fsf@zid.claresco.hr> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 19 Mar 2008 21:28:36 +0100 (CET) Cc: Subject: Re: Upgrading to 7.0 - stupid requirements X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, mlerota@iskon.hr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 20:28:38 -0000 Marko Lerota wrote: > This thing should be solved. I liked the way that my OS have > independance from ports. Well, they are not really completely independent. The ports still use libraries from the base OS, e.g. libc, threading libraries etc. Please try to understand the following simple example. The problem is this: Program A from ports links against library B from ports. Both programm A and libray B als link against libc.so.6 from the base OS (FreeBSD 6). Now you update to FreeBSD 7, but you don't update all the ports. Everything still works (even though FreeBSD has a new libc.so.7), because the old software uses libc.so.6 from the compat6x port. BUT ... As soon as you have to update the old library B because of a security problem or anything, you will run into problems: The new library B will link against the new libc.so.7, but the old program A (which uses library B) is still linked against the libc.do.6 from compat6x. So when you try to run program A, it will try to load both libc.so.6 and libc.so.7 (via library B), which will fail, because a binary cannot use two different versions of the same library at once. So program A stops working. Of course, rebuilding program A will solve the problem, so it links to the new libc.so.7, too. That's easy. But in practice it is a lot more complicated, because you have many ports with many binaries and many libraries, with many dependencies between them. You could try to run "pkg_info -R" each time you update something, so you can make sure to update all ports dependent on the one you update. If you do this every time, everything will continue to work, but it's tedious, and as soon as you forget something, you will run into trouble. Really, the easiest and most reliable way is to rebuild all ports (or download compiled packages) and be done with it. > So no metter what I do with ports, my OS and his apps will work. They _will_ work. The trouble only starts when you update some of the ports on which other ports depend, as explained above. > If this thing can be solved (I'm not programmer so I don't know) I can > donate some amount of $ for development. I think that this would make > lots of people happy. I have to admit I see no way how the problem could be solved in a different way, I'm afraid. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 20:34:17 2008 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 CB54B1065672 for ; Wed, 19 Mar 2008 20:34:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5888FC1B for ; Wed, 19 Mar 2008 20:34:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2JKYGeY024589; Wed, 19 Mar 2008 16:34:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m2JKYFmL087217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 16:34:15 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200803192034.m2JKYFmL087217@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Mar 2008 16:32:13 -0400 To: Jeremy Chadwick , freebsd-stable@freebsd.org, root@ha-web1.hockeyarena.net From: Mike Tancsa In-Reply-To: <20080319180629.GA29308@eos.sc1.parodius.com> References: <669936444.20080319100148@rulez.sk> <200803191753.m2JHraI5092556@lurza.secnetix.de> <20080319180629.GA29308@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Weird system cpu usage 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, 19 Mar 2008 20:34:17 -0000 At 02:06 PM 3/19/2008, Jeremy Chadwick wrote: >On Wed, Mar 19, 2008 at 06:53:36PM +0100, Oliver Fromme wrote: > > Charlie Root wrote: > > > root@[ha-web1 ~]# vmstat -i > > > interrupt total rate > > > irq1: atkbd0 12 0 > > > irq16: ohci0 1 0 > > > irq17: ohci1 ohci3 1 0 > > > irq18: ohci2 ohci4 1 0 > > > irq20: em0 86255835 1361 > > > irq22: em1 atapci0 18611379049 293795 > > > > Now that looks unusual indeed. Do you get that rate > > on irq22 right after boot, before the services have > > started? It looks like either hardware or driver > > problems. Do you have polling enabled on em1? > >Also, I believe there was a report from another user who saw similar >issues with em(4), and found that disabling MSI fixed the storm in >question. I believe you can disable MSI/MSIX by placing the following >in /boot/loader.conf, then reboot: > >hw.pci.enable_msi="0" >hw.pci.enable_msix="0" When MSI is enabled, the irq will be a strangely high number. e.g. % vmstat -i interrupt total rate irq4: sio0 76 0 irq17: em3 360 0 irq19: atapci1 2901 0 cpu0: timer 33719800 1999 irq257: em1 56571 3 irq258: em2 4 0 cpu1: timer 33717664 1999 Total 67497376 4003 If anything, I found enabling MSI helped matters where I saw strange IRQ issues. However, not sure if the original poster's hardware supports it. One thing it does remind me of is some strange IRQ issues I had on an AMD board where a USB setting for "legacy handoff" (something like that) would really slow down the machine with an in inordinate amount of IRQs firing. I forget if I had to enable it or disable it to fix the problem. If anything, I would try disabling USB all together if its not being used even though its not figuring in the above really high rate of IRQs. ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 21:02:55 2008 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 58888106566B for ; Wed, 19 Mar 2008 21:02:55 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 197808FC18 for ; Wed, 19 Mar 2008 21:02:54 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from localhost ([69.203.87.53]) by hrndva-omta04.mail.rr.com with ESMTP id <20080319204748.CNHQ12279.hrndva-omta04.mail.rr.com@localhost> for ; Wed, 19 Mar 2008 20:47:48 +0000 Date: Wed, 19 Mar 2008 16:47:48 -0400 From: Scott Robbins To: freebsd-stable@freebsd.org Message-ID: <20080319204748.GC61839@mail.scottro.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> <20080319193243.GA30784@eos.sc1.parodius.com> <000401c889f9$fab77c10$f0267430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <000401c889f9$fab77c10$f0267430$@com> User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: Re: Upgrading to 7.0 - stupid requirements 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, 19 Mar 2008 21:02:55 -0000 On Wed, Mar 19, 2008 at 03:46:52PM -0400, Kevin K wrote: > > That said: I do understand what you're saying, and yes, I can see why > > you would want that. It does make sense, and it's reasonable. It's > > just hard to achieve. I don't think other mainstream OSes (e.g. Linux) > > offer this ability either, though. Am I wrong? > > Redhat's up2date/yum ? I'm not 100% certain though. RedHat, some Debian versions and others aimed at the server market will have their precompiled binaries with reasonably sane defaults. (Or else with everything, including the kitchen sink, thrown in.) The downside is that the server based ones, (RH, CentOS, etc.,) are going to have older versions of packages. This makes sense of course. Much of the time, they'll simply concentrate on security updates and have a 5 year EOL (possibly longer, possibly shorter, but around that.) Desktop---well, things like Ubuntu and Fedora usually have major upgrades every 6 months or so. Fedora at least, recommends doing a complete reinstall, though usually, updating via their yum package manager will work. It doesn't always. Arch Linux and some others have a rolling release type thing, where incremental upgrades take place all the time, usually without major effect. They're smaller, and like the BSDs tend to be better at letting people know--(things similar to our HEADSUP type posts.) Fedora in contrast, might make a decision that will break sound for 30 percent of the users and the only way to find out will be to dig through their (rather slow) bugzilla, only to find that the developer doesn't consider it a bug. (That's not an insult aimed at the developer--they have their reasons which are often quite logical, but anyway...) -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: She must be right. We must have some kind of amnesia. Buffy: I don't know what that is, but I'm certain I don't have it. I bathe quite often. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 19 21:08:35 2008 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 F1F38106566B for ; Wed, 19 Mar 2008 21:08:35 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.freebsd.org (Postfix) with ESMTP id 6894B8FC12 for ; Wed, 19 Mar 2008 21:08:35 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 74C9D10E624; Wed, 19 Mar 2008 22:07:14 +0100 (CET) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW4Qs+QbqyjZ; Wed, 19 Mar 2008 22:07:12 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id CCC6410E647; Wed, 19 Mar 2008 22:07:12 +0100 (CET) Date: Wed, 19 Mar 2008 22:08:25 +0100 From: Daniel Gerzo X-Mailer: The Bat! (v3.99.3) Professional Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1839488629.20080319220825@rulez.sk> To: Mike Tancsa In-Reply-To: <200803192034.m2JKYFmL087217@lava.sentex.ca> References: <669936444.20080319100148@rulez.sk> <200803191753.m2JHraI5092556@lurza.secnetix.de> <20080319180629.GA29308@eos.sc1.parodius.com> <200803192034.m2JKYFmL087217@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re[2]: Weird system cpu usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 21:08:36 -0000 Hello Mike, Wednesday, March 19, 2008, 9:32:13 PM, you wrote: >>Also, I believe there was a report from another user who saw similar >>issues with em(4), and found that disabling MSI fixed the storm in >>question. I believe you can disable MSI/MSIX by placing the following >>in /boot/loader.conf, then reboot: >> >>hw.pci.enable_msi="0" >>hw.pci.enable_msix="0" > When MSI is enabled, the irq will be a strangely high number. e.g. Interesting, I have disabled MSI and MSIX support, but they still share the same irq. However, I don't know yet if the interrupt storm is going to be resolved, it needs some time (It always used to take some time until it has showed up). > If anything, I found enabling MSI helped matters where I saw strange > IRQ issues. However, not sure if the original poster's hardware > supports it. One thing it does remind me of is some strange IRQ > issues I had on an AMD board where a USB setting for "legacy handoff" > (something like that) would really slow down the machine with an in > inordinate amount of IRQs firing. I forget if I had to enable it or > disable it to fix the problem. If anything, I would try disabling > USB all together if its not being used even though its not figuring > in the above really high rate of IRQs. The USB isn't indeed used, I will think about disabling it, and also about trying to move around the em(4) NICs to the other slots. Unfortunately I don't have a physical access to the given maschine. -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 03:39:09 2008 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 6D97E1065673 for ; Thu, 20 Mar 2008 03:39:09 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 463E98FC12 for ; Thu, 20 Mar 2008 03:39:09 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so446945rvb.43 for ; Wed, 19 Mar 2008 20:39:08 -0700 (PDT) Received: by 10.140.126.10 with SMTP id y10mr553721rvc.214.1205984348815; Wed, 19 Mar 2008 20:39:08 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Wed, 19 Mar 2008 20:39:08 -0700 (PDT) Message-ID: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> Date: Thu, 20 Mar 2008 03:39:08 +0000 From: "Brad Pitney" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: machine wedged -> KDB: enter: lock violation 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, 20 Mar 2008 03:39:09 -0000 Not sure why it keeps wedging, at first I thought it was something to do with the LORs, now after adding some more debugging options I think I might have found the answer! KDB: stack backtrace: db_trace_self_wrapper(c074b5ee,e70599ac,c05b6853,c4a9e000,e70599ac,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4a9e000,e70599ac,c07025c5,e70599bc,c4c44d98,...) at kdb_backtrace+0x29 vfs_badlock(c4a37900,e70599bc,c07b00a0,c4c44d98,c4a9e000) at vfs_badlock+0x23 assert_vop_elocked(c4c44d98,c0752ee7,c4a9e000,1b9,0,...) at assert_vop_elocked+0x53 cache_lookup(c4c4815c,e7059bc0,e7059bd4,e7059bc0,c4aa4400,...) at cache_lookup+0x53c vfs_cache_lookup(e7059aa8,c07545ba,c4c4815c,2,c4c4815c,...) at vfs_cache_lookup+0xaa VOP_LOOKUP_APV(c4a37900,e7059aa8,c4a9e000,c075356a,19b,...) at VOP_LOOKUP_APV+0xe5 lookup(e7059bac,e7059ae8,c6,bf,c4aa542c,...) at lookup+0x53e namei(e7059bac,2,c0754d92,c0577808,c0811ae0,...) at namei+0x28e kern_stat(c4a9e000,2820258c,0,e7059c1c,c074d152,...) at kern_stat+0x3d stat(c4a9e000,e7059cfc,8,c074e1dc,c0785e00,...) at stat+0x2f syscall(e7059d38) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x281aa48f, esp = 0xbfbfea4c, ebp = 0xbfbfeae8 --- cache_lookup: 0xc4c44d98 is not exclusive locked but should be KDB: enter: lock violation Locked vnodes 0xc4a10828: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 499318, on dev ad0s3a 0xc49cc414: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a344c3 at unionfs_lock+0x173 #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 141664, on dev ad0s3a 0xc48f62b8: tag ufs, type VREG usecount 6, writecount 0, refcount 9 mountedhere 0 flags (VV_TEXT) v_object 0xc4c5f364 ref 3 pages 63 lock type ufs: SHARED (count 1)#0 0xc052fab5 at _lockmgr+0x1c5 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc05c53b8 at _vn_lock+0xf8 #4 0xc05ba130 at vget+0x110 #5 0xc0699c20 at vnode_pager_lock+0x1b0 #6 0xc06825df at vm_fault+0x1df #7 0xc06ec478 at trap_pfault+0x118 #8 0xc06ecd07 at trap+0x2b7 #9 0xc06d5ecb at calltrap+0x6 ino 144832, on dev ad0s3a 0xc4c4815c: tag unionfs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 unionfs_vp=0xc4c4815c, uppervp=0xc4a10828, lowervp=0xc49cc414 unionfs: upper 0xc4a10828: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 499318, on dev ad0s3a unionfs: lower 0xc49cc414: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a344c3 at unionfs_lock+0x173 #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 141664, on dev ad0s3a Locked vnodes 0xc4a10828: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 499318, on dev ad0s3a 0xc49cc414: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a344c3 at unionfs_lock+0x173 #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 141664, on dev ad0s3a 0xc48f62b8: tag ufs, type VREG usecount 6, writecount 0, refcount 9 mountedhere 0 flags (VV_TEXT) v_object 0xc4c5f364 ref 3 pages 63 lock type ufs: SHARED (count 1)#0 0xc052fab5 at _lockmgr+0x1c5 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc05c53b8 at _vn_lock+0xf8 #4 0xc05ba130 at vget+0x110 #5 0xc0699c20 at vnode_pager_lock+0x1b0 #6 0xc06825df at vm_fault+0x1df #7 0xc06ec478 at trap_pfault+0x118 #8 0xc06ecd07 at trap+0x2b7 #9 0xc06d5ecb at calltrap+0x6 ino 144832, on dev ad0s3a 0xc4c4815c: tag unionfs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 unionfs_vp=0xc4c4815c, uppervp=0xc4a10828, lowervp=0xc49cc414 unionfs: upper 0xc4a10828: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a345aa at unionfs_lock+0x25a #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 499318, on dev ad0s3a unionfs: lower 0xc49cc414: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc4a9e000 (pid 85094)#0 0xc052fe50 at _lockmgr+0x560 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc4a344c3 at unionfs_lock+0x173 #4 0xc0705775 at VOP_LOCK1_APV+0xa5 #5 0xc05c53b8 at _vn_lock+0xf8 #6 0xc05ba130 at vget+0x110 #7 0xc05a9657 at cache_lookup+0x4e7 #8 0xc05a978a at vfs_cache_lookup+0xaa #9 0xc0706915 at VOP_LOOKUP_APV+0xe5 #10 0xc05af3ee at lookup+0x53e #11 0xc05afe6e at namei+0x28e #12 0xc05bd5ad at kern_stat+0x3d #13 0xc05bd73f at stat+0x2f #14 0xc06ec7e3 at syscall+0x273 #15 0xc06d5f30 at Xint0x80_syscall+0x20 ino 141664, on dev ad0s3a the box was running CURRENT until it was branched for RELENG_7 which was running code from September 2007 fine until I updated to "todays" code I get my problems. I don't know, I've been running FreeBSD for a few years, never had anything this serious -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 05:03:41 2008 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 54815106564A for ; Thu, 20 Mar 2008 05:03:41 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (209-193-47-81-cdsl-rb1.fai.acsalaska.net [209.193.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id B32C78FC1A for ; Thu, 20 Mar 2008 05:03:40 +0000 (UTC) (envelope-from pstern@jago.65north.com) Received: from jago.65north.com (localhost.65north.com [127.0.0.1]) by jago.65north.com (8.13.3/8.13.3) with ESMTP id m2K53Ibw015768; Wed, 19 Mar 2008 21:03:18 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Received: from localhost (pstern@localhost) by jago.65north.com (8.13.3/8.13.3/Submit) with ESMTP id m2K53FBd015765; Wed, 19 Mar 2008 21:03:16 -0800 (AKDT) (envelope-from pstern@jago.65north.com) Date: Wed, 19 Mar 2008 21:03:15 -0800 (AKDT) From: peter stern To: Kevin Oberman In-Reply-To: <20080318142235.989DE45014@ptavv.es.net> Message-ID: <20080319205745.N15619@jago.65north.com> References: <20080318142235.989DE45014@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kurt Jaeger , freebsd-stable@freebsd.org Subject: Re: recovering from the 6.3 xorg mess 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, 20 Mar 2008 05:03:41 -0000 On Tue, 18 Mar 2008, Kevin Oberman wrote: >> Date: Mon, 17 Mar 2008 21:23:09 -0800 (AKDT) >> From: peter stern >> >> >> This is an ugly way to have to deal with X. So this definitely means the >> mga driver is broken? >> >> I would appreciate a copy of your xorg.conf >> >> Thanks for your suggestions. >> >> peter > > Peter, > > Here is the config file from my G550 dual-head system. I won't promise > that it is "correct". In fact, I suspect it is not, but it works for me. > > Section "ServerLayout" > Identifier "xrandr" > Screen 0 "Screen0" 0 0 > InputDevice "Mouse0" "CorePointer" > InputDevice "Keyboard0" "CoreKeyboard" > EndSection > > Section "Files" > RgbPath "/usr/local/share/X11/rgb" > ModulePath "/usr/local/lib/xorg/modules" > FontPath "/usr/local/lib/X11/fonts/bitstream-vera/" > FontPath "/usr/local/lib/X11/fonts/URW/" > FontPath "/usr/local/lib/X11/fonts/urwfonts-ttf/" > EndSection > > Section "DRI" > Mode 0666 > EndSection > > Section "Extensions" > Option "Composite" "Disable" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbOptions" "ctrl:swapcaps" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "Monitor" > #DisplaySize 370 300 # mm > Identifier "Monitor0" > VendorName "DEL" > ModelName "DELL 1701FP" > ### Comment all HorizSync and VertSync values to use DDC: > # HorizSync 24.0 - 80.0 > # VertRefresh 56.0 - 75.0 > Option "DPMS" > Option "Position" "0 0" > EndSection > > Section "Monitor" > Identifier "Monitor1" > VendorName "DEL" > ModelName "DELL 1701FP" > HorizSync 24.0 - 36.0 > VertRefresh 56.0 - 75.0 > Option "DPMS" > Option "Position" "1280 0" > EndSection > > Section "Device" > Identifier "Card0" > Driver "mga" > VendorName "Matrox Graphics, Inc." > BoardName "MGA G400/G450" > BusID "PCI:1:0:0" > Option "HWcursor" "off" > Option "AGPMode" "4" > Option "Monitor-VGA1" "Monitor0" > Option "Monitor-VGA2" "Monitor1" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Virtual 2560 1024 > EndSubSection > EndSection > > -- > 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 > I looked through my xorg.conf and it looked fairly similar. I do not have Identifier "xrandr" Screen 0 "Screen0" 0 0 I don't have DRI enabled. I have moved this discussion over to the freebsd-x11 list in the hope someone there might be able to figure this out. I guess for now, I have to be happy that xrandr control makes life with the mga device semi-tolerable. Thanks, peter From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 07:16:08 2008 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 85EA71065671 for ; Thu, 20 Mar 2008 07:16:08 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 483378FC24 for ; Thu, 20 Mar 2008 07:16:08 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 8ED26405BFF for ; Thu, 20 Mar 2008 08:16:06 +0100 (CET) Message-ID: <47E20F35.5060200@bsdforen.de> Date: Thu, 20 Mar 2008 08:16:05 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.12 (X11/20080310) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: moused freezes Xorg - caused by compiler bug 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, 20 Mar 2008 07:16:08 -0000 I have long been annoyed by the problem that Xorg is frozen if I use moused, unless the mouse is in movement. Just imagine you type something and it only shows up when you move your mouse. Or if you watch a video ... you basically have to keep the mouse in movement all the time. I am/have been using the following CPUTYPEs on different machines: pentium4 - not affected pentium-m - affected core2/nocona - affected I just had the idea this might be an optimization problem and I rebuild src/usr.sbin/moused with CPUTYPE=athlon64 and it works. I've put the following into my make.conf: # moused bug workaround .if ${.CURDIR:M*/usr.sbin/moused} .if defined(CPUTYPE) .if ${CPUTYPE} == core2 CPUTYPE=athlon64 .elif ${CPUTYPE} == pentium-m CPUTYPE=pentium3 .endif .endif .endif From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 07:48:36 2008 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 DFFAF106564A for ; Thu, 20 Mar 2008 07:48:36 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id A865C8FC26 for ; Thu, 20 Mar 2008 07:48:36 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from [192.168.1.38] (a89-182-206-17.net-htp.de [89.182.206.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTP id 37A65A37383 for ; Thu, 20 Mar 2008 08:31:08 +0100 (CET) From: Heiko Wundram To: freebsd-stable@freebsd.org Date: Thu, 20 Mar 2008 08:32:16 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803200832.16340.modelnine@modelnine.org> Subject: pthread_mutexattr_settype non-conformance to man-page and POSIX 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, 20 Mar 2008 07:48:37 -0000 I hit a bug in libthr with pthread_mutexattr_settype which (at least as far as I understand the POSIX reference and also the man-page) makes it non-conformant to the specifications. Quoting: """ RETURN VALUES If successful, these functions return 0. Otherwise, an error number is returned to indicate the error. ... ERRORS ... The pthread_mutexattr_settype() function will fail if: [EINVAL] Invalid value for attr, or invalid value for type. """ This does not happen (at least not in libthr): """ int _pthread_mutexattr_settype(pthread_mutexattr_t *attr, int type) { int ret; if (attr == NULL || *attr == NULL || type >= PTHREAD_MUTEX_TYPE_MAX) { errno = EINVAL; ret = -1; } else { (*attr)->m_type = type; ret = 0; } return(ret); } """ The error code EINVAL is stored to errno, and -1 is returned, which is wrong at least according to my understanding of the man-page, which pretty much says the same thing as POSIX. I haven't looked yet whether this code has always been this way for FreeBSD, but at least under glibc[+NPTL], the error-number is returned directly as the return value (from a quick skimming of the sources), just as I would understand the specifications. The code in question is similar to pretty much all other functions in libthr, which also set errno and return -1, so basically it's a systematic error in the implementation of libthr, if I'm not completely mistaken. Anybody else have any more insight on this? -- Heiko Wundram From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 08:28:01 2008 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D87F1065672 for ; Thu, 20 Mar 2008 08:28:01 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA1E8FC1C; Thu, 20 Mar 2008 08:28:01 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2K8RvTq010997; Thu, 20 Mar 2008 08:27:58 GMT (envelope-from davidxu@freebsd.org) Message-ID: <47E2205E.60902@freebsd.org> Date: Thu, 20 Mar 2008 16:29:18 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Heiko Wundram References: <200803200832.16340.modelnine@modelnine.org> In-Reply-To: <200803200832.16340.modelnine@modelnine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: pthread_mutexattr_settype non-conformance to man-page and POSIX 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, 20 Mar 2008 08:28:01 -0000 Heiko Wundram wrote: > I hit a bug in libthr with pthread_mutexattr_settype which (at least as far as > I understand the POSIX reference and also the man-page) makes it > non-conformant to the specifications. > > Quoting: > > """ > RETURN VALUES > If successful, these functions return 0. Otherwise, an error number is > returned to indicate the error. > ... > ERRORS > ... > The pthread_mutexattr_settype() function will fail if: > > [EINVAL] Invalid value for attr, or invalid value for type. > """ > Fixed, thanks! David Xu From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 10:20:45 2008 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 ABD401065670; Thu, 20 Mar 2008 10:20:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D19E38FC1C; Thu, 20 Mar 2008 10:20:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E23A7F.3020807@FreeBSD.org> Date: Thu, 20 Mar 2008 11:20:47 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brad Pitney References: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> In-Reply-To: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: daichi@FreeBSD.org, "freebsd-stable@freebsd.org" Subject: Re: machine wedged -> KDB: enter: lock violation 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, 20 Mar 2008 10:20:45 -0000 Brad Pitney wrote: > Not sure why it keeps wedging, at first I thought it was something to > do with the LORs, now after adding some more debugging options I > think I might have found the answer! > > KDB: stack backtrace: > db_trace_self_wrapper(c074b5ee,e70599ac,c05b6853,c4a9e000,e70599ac,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c4a9e000,e70599ac,c07025c5,e70599bc,c4c44d98,...) at > kdb_backtrace+0x29 > vfs_badlock(c4a37900,e70599bc,c07b00a0,c4c44d98,c4a9e000) at vfs_badlock+0x23 > assert_vop_elocked(c4c44d98,c0752ee7,c4a9e000,1b9,0,...) at > assert_vop_elocked+0x53 > cache_lookup(c4c4815c,e7059bc0,e7059bd4,e7059bc0,c4aa4400,...) at > cache_lookup+0x53c > vfs_cache_lookup(e7059aa8,c07545ba,c4c4815c,2,c4c4815c,...) at > vfs_cache_lookup+0xaa > VOP_LOOKUP_APV(c4a37900,e7059aa8,c4a9e000,c075356a,19b,...) at > VOP_LOOKUP_APV+0xe5 > lookup(e7059bac,e7059ae8,c6,bf,c4aa542c,...) at lookup+0x53e > namei(e7059bac,2,c0754d92,c0577808,c0811ae0,...) at namei+0x28e > kern_stat(c4a9e000,2820258c,0,e7059c1c,c074d152,...) at kern_stat+0x3d > stat(c4a9e000,e7059cfc,8,c074e1dc,c0785e00,...) at stat+0x2f > syscall(e7059d38) at syscall+0x273 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (188, FreeBSD ELF32, stat), eip = 0x281aa48f, esp = > 0xbfbfea4c, ebp = 0xbfbfeae8 --- > cache_lookup: 0xc4c44d98 is not exclusive locked but should be > KDB: enter: lock violation > > Locked vnodes [...] Apparently 0xc4c44d98 is not locked at all, it didnt appear in your list. Are you sure that was all of it? What does 'show vnode 0xc4c44d98' report? This is likely to be a unionfs bug. Kris From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 11:19:23 2008 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 2B59C106564A for ; Thu, 20 Mar 2008 11:19:23 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 18CE98FC1A for ; Thu, 20 Mar 2008 11:19:22 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so539675rvb.43 for ; Thu, 20 Mar 2008 04:19:22 -0700 (PDT) Received: by 10.141.70.18 with SMTP id x18mr605932rvk.284.1206011962603; Thu, 20 Mar 2008 04:19:22 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Thu, 20 Mar 2008 04:19:22 -0700 (PDT) Message-ID: <3dd203290803200419w3565bf3fpdf499ea96f11cb86@mail.gmail.com> Date: Thu, 20 Mar 2008 11:19:22 +0000 From: "Brad Pitney" To: "Kris Kennaway" In-Reply-To: <47E23A7F.3020807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> <47E23A7F.3020807@FreeBSD.org> Cc: daichi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: machine wedged -> KDB: enter: lock violation 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, 20 Mar 2008 11:19:23 -0000 On Thu, Mar 20, 2008 at 10:20 AM, Kris Kennaway wrote: > > Brad Pitney wrote: > > Not sure why it keeps wedging, at first I thought it was something to > > do with the LORs, now after adding some more debugging options I > > think I might have found the answer! > > > > KDB: stack backtrace: > > db_trace_self_wrapper(c074b5ee,e70599ac,c05b6853,c4a9e000,e70599ac,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c4a9e000,e70599ac,c07025c5,e70599bc,c4c44d98,...) at > > kdb_backtrace+0x29 > > vfs_badlock(c4a37900,e70599bc,c07b00a0,c4c44d98,c4a9e000) at vfs_badlock+0x23 > > assert_vop_elocked(c4c44d98,c0752ee7,c4a9e000,1b9,0,...) at > > assert_vop_elocked+0x53 > > cache_lookup(c4c4815c,e7059bc0,e7059bd4,e7059bc0,c4aa4400,...) at > > cache_lookup+0x53c > > vfs_cache_lookup(e7059aa8,c07545ba,c4c4815c,2,c4c4815c,...) at > > vfs_cache_lookup+0xaa > > VOP_LOOKUP_APV(c4a37900,e7059aa8,c4a9e000,c075356a,19b,...) at > > VOP_LOOKUP_APV+0xe5 > > lookup(e7059bac,e7059ae8,c6,bf,c4aa542c,...) at lookup+0x53e > > namei(e7059bac,2,c0754d92,c0577808,c0811ae0,...) at namei+0x28e > > kern_stat(c4a9e000,2820258c,0,e7059c1c,c074d152,...) at kern_stat+0x3d > > stat(c4a9e000,e7059cfc,8,c074e1dc,c0785e00,...) at stat+0x2f > > syscall(e7059d38) at syscall+0x273 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (188, FreeBSD ELF32, stat), eip = 0x281aa48f, esp = > > 0xbfbfea4c, ebp = 0xbfbfeae8 --- > > cache_lookup: 0xc4c44d98 is not exclusive locked but should be > > KDB: enter: lock violation > > > > Locked vnodes > > [...] > > Apparently 0xc4c44d98 is not locked at all, it didnt appear in your > list. Are you sure that was all of it? What does 'show vnode > 0xc4c44d98' report? > it's possible it isn't all of it :( - is it the only other information that might be needed if it happens again? which is highly likely, I've had to reboot the box about 3 times a day on average. Worst part is it never happens when I am logged in to the box, grr. my unionfs mount looks like this: :/var/jail/nub01 on /var/jail/nub02 (unionfs, local, noatime) I do have another problem with devfs, but might be related to unionfs Starting jails: nub01 devfs ruleset: ioctl DEVFSIO_SUSE : Inappropriate ioctl for device /etc/rc: WARNING: devfs_set_ruleset: unable to set ruleset 4 to /var/jail/nub02/dev devfs rule: ioctl DEVFSIO_SAPPLY : Inappropriate ioctl for device nub02 . > This is likely to be a unionfs bug. Ok, I can remake the jail without using uniionfs. Strange how it worked no problem before. Could the jails being out of sync cause the problem? when I say out of sync, I mean they are still from code that was from September 2007, although from discussions on the mailing lists, I think you can get away with running RELENG_6 under jail without problems. > > Kris > -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 11:26:02 2008 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 B6A30106564A for ; Thu, 20 Mar 2008 11:26:02 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 88DAE8FC15 for ; Thu, 20 Mar 2008 11:26:02 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by wr-out-0506.google.com with SMTP id 50so819202wra.13 for ; Thu, 20 Mar 2008 04:26:01 -0700 (PDT) Received: by 10.141.190.9 with SMTP id s9mr610058rvp.110.1206012361297; Thu, 20 Mar 2008 04:26:01 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Thu, 20 Mar 2008 04:26:01 -0700 (PDT) Message-ID: <3dd203290803200426u7fc12227h8eede8095fac3970@mail.gmail.com> Date: Thu, 20 Mar 2008 11:26:01 +0000 From: "Brad Pitney" To: "Kris Kennaway" In-Reply-To: <47E23A7F.3020807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> <47E23A7F.3020807@FreeBSD.org> Cc: daichi@freebsd.org, "freebsd-stable@freebsd.org" Subject: Re: machine wedged -> KDB: enter: lock violation 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, 20 Mar 2008 11:26:02 -0000 On Thu, Mar 20, 2008 at 10:20 AM, Kris Kennaway wrote: > [..] > This is likely to be a unionfs bug. > unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 unionfs_close: warning: open count is 0 after doing periodic daily both in the jail and outside. > Kris > -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 11:46:49 2008 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 710ED1065673 for ; Thu, 20 Mar 2008 11:46:49 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA618FC1A for ; Thu, 20 Mar 2008 11:46:49 +0000 (UTC) (envelope-from pitney.brad@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so544651rvb.43 for ; Thu, 20 Mar 2008 04:46:48 -0700 (PDT) Received: by 10.141.68.12 with SMTP id v12mr613961rvk.111.1206013608811; Thu, 20 Mar 2008 04:46:48 -0700 (PDT) Received: by 10.141.41.8 with HTTP; Thu, 20 Mar 2008 04:46:48 -0700 (PDT) Message-ID: <3dd203290803200446g7bca42b4h138252adadf9c53d@mail.gmail.com> Date: Thu, 20 Mar 2008 11:46:48 +0000 From: "Brad Pitney" To: "Kris Kennaway" In-Reply-To: <47E23A7F.3020807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3dd203290803192039y2f905ae1m36833978a2799e29@mail.gmail.com> <47E23A7F.3020807@FreeBSD.org> Cc: daichi@freebsd.org, "freebsd-stable@freebsd.org" Subject: Re: machine wedged -> KDB: enter: lock violation 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, 20 Mar 2008 11:46:49 -0000 once again: KDB: stack backtrace: db_trace_self_wrapper(c074b5ee,e70c79ac,c05b6853,c4b8c420,e70c79ac,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c4b8c420,e70c79ac,c07025c5,e70c79bc,c4c002b8,...) at kdb_backtrace+0x29 vfs_badlock(c4a31900,e70c79bc,c07b00a0,c4c002b8,c4b8c420) at vfs_badlock+0x23 assert_vop_elocked(c4c002b8,c0752ee7,c4b8c420,1b9,0,...) at assert_vop_elocked+0x53 cache_lookup(c4bfe414,e70c7bc0,e70c7bd4,e70c7bc0,c49c5800,...) at cache_lookup+0x53c vfs_cache_lookup(e70c7aa8,c07545ba,c4bfe414,2,c4bfe414,...) at vfs_cache_lookup+0xaa VOP_LOOKUP_APV(c4a31900,e70c7aa8,c4b8c420,c075356a,19b,...) at VOP_LOOKUP_APV+0xe5 lookup(e70c7bac,e70c7ae8,c6,bf,c49acc2c,...) at lookup+0x53e namei(e70c7bac,2,c0754d92,c0577808,c08119c8,...) at namei+0x28e kern_stat(c4b8c420,2820258c,0,e70c7c1c,c074d152,...) at kern_stat+0x3d stat(c4b8c420,e70c7cfc,8,c074e1dc,c0785e00,...) at stat+0x2f syscall(e70c7d38) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x281aa48f, esp = 0xbfbfea4c, ebp = 0xbfbfeae8 --- cache_lookup: 0xc4c002b8 is not exclusive locked but should be KDB: enter: lock violation vnode 0xc4c002b8: tag unionfs, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VV_TEXT|VI_FREE|VI_OWEINACT) v_object 0xc4b866c8 ref 0 pages 158 #0 0xc052fab5 at _lockmgr+0x1c5 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc05c53b8 at _vn_lock+0xf8 #4 0xc05ba130 at vget+0x110 #5 0xc0699c20 at vnode_pager_lock+0x1b0 #6 0xc06825df at vm_fault+0x1df #7 0xc06ec478 at trap_pfault+0x118 #8 0xc06ecd07 at trap+0x2b7 #9 0xc06d5ecb at calltrap+0x6 unionfs_vp=0xc4c002b8, uppervp=0xc4b91414, lowervp=0xc4b9115c unionfs: upper 0xc4b91414: tag ufs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc4b866c8 ref 0 pages 158 #0 0xc052fab5 at _lockmgr+0x1c5 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc05c53b8 at _vn_lock+0xf8 #4 0xc05ba130 at vget+0x110 #5 0xc0699c20 at vnode_pager_lock+0x1b0 #6 0xc06825df at vm_fault+0x1df #7 0xc06ec478 at trap_pfault+0x118 #8 0xc06ecd07 at trap+0x2b7 #9 0xc06d5ecb at calltrap+0x6 ino 500700, on dev ad0s3a unionfs: lower 0xc4b9115c: tag ufs, type VREG usecount 4, writecount 0, refcount 7 mountedhere 0 flags (VV_TEXT) v_object 0xc4be1aa8 ref 2 pages 109 #0 0xc052fab5 at _lockmgr+0x1c5 #1 0xc0668df1 at ffs_lock+0x91 #2 0xc0705775 at VOP_LOCK1_APV+0xa5 #3 0xc05c53b8 at _vn_lock+0xf8 #4 0xc05ba130 at vget+0x110 #5 0xc0699c20 at vnode_pager_lock+0x1b0 #6 0xc06825df at vm_fault+0x1df #7 0xc06ec478 at trap_pfault+0x118 #8 0xc06ecd07 at trap+0x2b7 #9 0xc06d5ecb at calltrap+0x6 ino 144832, on dev ad0s3a -- Best regards, Brad From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 14:23:34 2008 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 F3B20106564A for ; Thu, 20 Mar 2008 14:23:33 +0000 (UTC) (envelope-from rabe@uugrn.org) Received: from mail.uugrn.org (mail.uugrn.org [195.49.138.123]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF628FC33 for ; Thu, 20 Mar 2008 14:23:33 +0000 (UTC) (envelope-from rabe@uugrn.org) Received: from rabe.uugrn.org (root@rabe.uugrn.org [195.49.138.102]) by mail.uugrn.org (8.13.8/8.13.8) with ESMTP id m2KENMXm074322 for ; Thu, 20 Mar 2008 15:23:32 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from daemon.ma.sigsys.de (rabe@rabe.uugrn.org [195.49.138.102]) by rabe.uugrn.org (8.13.8/8.13.8) with ESMTP id m2KENLj7074295 for ; Thu, 20 Mar 2008 15:23:21 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from daemon.ma.sigsys.de (localhost.ma.sigsys.de [127.0.0.1]) by daemon.ma.sigsys.de (8.14.2/8.13.1) with ESMTP id m2KENji2007874 for ; Thu, 20 Mar 2008 15:23:45 +0100 (CET) (envelope-from rabe@uugrn.org) Received: (from rabe@localhost) by daemon.ma.sigsys.de (8.14.2/8.14.2/Submit) id m2KENjC4007873 for freebsd-stable@freebsd.org; Thu, 20 Mar 2008 15:23:45 +0100 (CET) (envelope-from rabe@uugrn.org) X-Authentication-Warning: daemon.ma.sigsys.de: rabe set sender to rabe@uugrn.org using -f Date: Thu, 20 Mar 2008 15:23:45 +0100 From: Raphael Becker To: freebsd-stable@freebsd.org Message-ID: <20080320142345.GA6825@ma.sigsys.de> References: <20080318150452.GA1561@ma.sigsys.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <20080318150452.GA1561@ma.sigsys.de> User-Agent: Mutt/1.4.2.3i Subject: Re: Using /etc/rc.d/geli with labeled devices on 6.3 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, 20 Mar 2008 14:23:34 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2008 at 04:04:52PM +0100, Raphael Becker wrote: [ getting /dev/label/FOOcrypt.eli configured through /etc/rc.d/geli ] > How should I set up /etc/rc.conf to get this by /etc/rc.d/geli on boot? >=20 > geli_enable=3D"YES" > geli_devices=3D"label/FOOcrypt" > geli_label/FOOcrypt_flags=3D"-k /root/keys/geli.FOO.key" > ^^^^^^^^^^^^^^=20 > This won't work. How? geli_label_FOOcrytp_flags=3D"-k /root/keys/geli.FOO.key"=20 ^^^ from /etc/rc.d/geli: provider_=3D`ltr ${provider} '/' '_'` eval "flags=3D\${geli_${provider_}_flags}" Seems to work. This should be documented in rc.conf(5) as ppl who use=20 'geli' for encryption might also know about and use 'glabel'. Regards Raphael Becker --=20 Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D =2E........|.........|.........|.........|.........|.........|.........|.. --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFH4nNxnNo+exDKny0RAprAAKC41Lqbm/UmR1OFfMkOeuuX/5OUYACg2dVM Rhf7QGPVt5T6RtDlSgndNkM= =hCQQ -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 20 20:50:36 2008 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 DFFC31065675; Thu, 20 Mar 2008 20:50:36 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 97EC38FC19; Thu, 20 Mar 2008 20:50:36 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id 7175F248F9DC; Thu, 20 Mar 2008 19:31:59 +0100 (CET) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 9A0EF3F85D1; Thu, 20 Mar 2008 21:20:36 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id AB0CE3F64C8; Thu, 20 Mar 2008 20:51:18 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 3790F9BF12; Thu, 20 Mar 2008 19:50:12 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 1FA93405D; Thu, 20 Mar 2008 20:50:12 +0100 (CET) Date: Thu, 20 Mar 2008 20:50:12 +0100 From: Jeremie Le Hen To: Unga Message-ID: <20080320195012.GA66530@obiwan.tataz.chchile.org> References: <945136.92642.qm@web57010.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <945136.92642.qm@web57010.mail.re3.yahoo.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-chat@freebsd.org Subject: Re: The Design and Implementation of the FreeBSD Operating 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: Thu, 20 Mar 2008 20:50:37 -0000 Hi, On Fri, Mar 14, 2008 at 07:41:30AM -0700, Unga wrote: > Is the following book still relevant to FreeBSD 7.X > and upcoming FreeBSD 8.X? Is there a 2nd edition > coming soon? > > The Design and Implementation of the FreeBSD Operating > System > By Marshall Kirk McKusick, George V. Neville-Neil > Published Aug 2, 2004 by Addison Wesley Professional. > 1st. Edition > ISBN-10: 0-201-70245-2 > http://www.informit.com/title/0201702452 FWIW there has been rumours about the next edition of this book covering a recenter version. That's all I know :). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-stable@FreeBSD.ORG Fri Mar 21 04:59:32 2008 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 E3B89106564A for ; Fri, 21 Mar 2008 04:59:32 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0FB8FC13 for ; Fri, 21 Mar 2008 04:59:32 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m2L4xSuF000337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 15:59:30 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m2L4xSew085953; Fri, 21 Mar 2008 15:59:28 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m2L4xRAB085952; Fri, 21 Mar 2008 15:59:27 +1100 (EST) (envelope-from peter) Date: Fri, 21 Mar 2008 15:59:27 +1100 From: Peter Jeremy To: Marko Lerota Message-ID: <20080321045927.GA85901@server.vk2pj.dyndns.org> References: <867igo3cih.fsf@zid.claresco.hr> <47C749CF.4010501@FreeBSD.org> <86eja7et3j.fsf@zid.claresco.hr> <47E0249C.8030700@FreeBSD.org> <868x0ezh9u.fsf@zid.claresco.hr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <868x0ezh9u.fsf@zid.claresco.hr> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 21 Mar 2008 04:59:33 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote: >time from ports because there are only small portion of precompiled=20 >packages. There should be a fairly complete set of packages for 7.0-RELEASE. There can never be a totally complete set of packages for legal reasons - the licenses on some ports do not permit them to be packaged. >This thing should be solved. Please offer some suggestions on how you would resolve the problem. >And If I upgrade the OS I dont want to recompile ports for that. You don't have to upgrade ports immediately. It's just that you can't upgrade any single port without re-building everything - for reasons that have been spelled out elsewhere in this thread. FWIW, the move to versioned symbols should (in theory) remove the need to need to do a future complete recompile once you've rebuilt all your ports against 7.x. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkfjQK8ACgkQ/opHv/APuIdh7ACfS5/eeCko4Iff/LHuw5GfhS2m DdEAniSrxNz+gzo9BUrfh75Oc43uRz7l =hWUu -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 21 11:56:40 2008 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 ACC4E1065673 for ; Fri, 21 Mar 2008 11:56:40 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9FF8FC1D for ; Fri, 21 Mar 2008 11:56:39 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 9A413119D65; Fri, 21 Mar 2008 12:41:01 +0100 (CET) Date: Fri, 21 Mar 2008 12:41:01 +0100 From: Victor Balada Diaz To: freebsd-stable@freebsd.org Message-ID: <20080321114101.GA61993@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Subject: FreeBSD 7.0 USB keyboard problems 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, 21 Mar 2008 11:56:40 -0000 Hello, i have a Sony VAIO VGC LA3[1] that just have USB wireless keyboard. On the BIOS i can't modify if the legacy mode it's enabled or not but i think it is enabled. In the loader everything works fine and i can type without problems but once i get to sysinstall the keyboard acts like if it had the ctrl key pressed all the time. So eg if i try to write an f the cursor position moves forward, if i press a it goes to the start of he line, etc. I googled and found that people was suggesting putting in the loader prompt the following values: hint.atkbd.0.disable="1" hint.atkbdc.0.disable="1" but they didn't make any difference. I also tried using DragonFlyBSD and the keyboard works fine there. What else can i try? Thanks in advance. Regards. [1]: http://vaio.sony.co.uk/view/ShowProduct.action?category=VD+LA+Series&product=VGC-LA3&site=voe_en_GB_cons -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 21 17:45:29 2008 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 A8B6B106566B for ; Fri, 21 Mar 2008 17:45:29 +0000 (UTC) (envelope-from gdoe6545@yahoo.it) Received: from mx.smershnet.com (mx.smershnet.com [87.117.208.209]) by mx1.freebsd.org (Postfix) with ESMTP id DDD808FC21 for ; Fri, 21 Mar 2008 17:45:28 +0000 (UTC) (envelope-from gdoe6545@yahoo.it) Received: from localhost (mx.smershnet.com [87.117.208.209]) by mx.smershnet.com (Postfix) with ESMTP id 0FEB72754881 for ; Fri, 21 Mar 2008 17:27:24 +0000 (GMT) X-Virus-Scanned: amavisd-new at smershnet.com Received: from mx.smershnet.com ([87.117.208.209]) by localhost (mx.smershnet.com [87.117.208.209]) (amavisd-new, port 10024) with ESMTP id k+WE7mRVf8LI for ; Fri, 21 Mar 2008 17:27:21 +0000 (GMT) Received: from kananga.hq.smershnet.com (217-133-13-140.b2b.tiscali.it [217.133.13.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.smershnet.com (Postfix) with ESMTP id C20BA2754880 for ; Fri, 21 Mar 2008 17:27:20 +0000 (GMT) Received: from zao.smersh.casa (zao.smersh.casa [192.168.200.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by kananga.hq.smershnet.com (Postfix) with ESMTPS id 4E60756446 for ; Fri, 21 Mar 2008 18:26:54 +0100 (CET) Message-Id: From: Gianni Doe 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 v919.2) Date: Fri, 21 Mar 2008 18:27:19 +0100 X-Mailer: Apple Mail (2.919.2) Subject: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE 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, 21 Mar 2008 17:45:29 -0000 I'm also experiencing this issue after upgrading to 7.0-RELEASE from 6.3 I've got 2 Western Digital 5000YS hard drives in a GEOM Raid 1 configuration and connected to a Promise on-board SATA controller, this has worked flawlessly under 6.3 but since upgrading to 7.0 I'm getting the DMA timeouts under intense write activity. I get the errors below and then after having to hard-reset the mirror rebuilds from scratch :( I've pasted dmesg below if that is of any help. Really desperate for a solution here as I don't fancy reverting to 6.3, let me know if there is any other info I can provide that may help identify the problem. -Gianni Mar 21 17:50:07 kananga kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:11 kananga kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:15 kananga kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Mar 21 17:50:19 kananga kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Mar 21 17:50:23 kananga kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Mar 21 17:50:23 kananga kernel: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=193407827 Mar 21 17:50:27 kananga kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:31 kananga kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:35 kananga kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Mar 21 17:50:39 kananga kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Mar 21 17:50:43 kananga kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Mar 21 17:50:43 kananga kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=193297119 Mar 21 17:50:47 kananga kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:51 kananga kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:50:55 kananga kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Mar 21 17:50:59 kananga kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Mar 21 17:51:03 kananga kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Mar 21 17:51:03 kananga kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=193297119 Mar 21 17:51:07 kananga kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:51:11 kananga kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 21 17:51:15 kananga kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Mar 21 17:51:19 kananga kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Copyright (c) 1992-2008 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.0-STABLE #2: Sun Mar 16 22:48:09 CET 2008 root@kananga.smersh.casa:/usr/obj/usr/src/sys/KANANGA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2002.58-MHz K8- class CPU) Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1 Features = 0x178bfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 usable memory = 1063124992 (1013 MB) avail memory = 1024499712 (977 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe0ff mem 0xe8000000-0xefffffff,0xfbe00000-0xfbe0ffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xf0000000-0xf7ffffff, 0xfbf00000-0xfbf0ffff at device 0.1 on pci1 fwohci0: port 0x8400-0x847f mem 0xfb300000-0xfb3007ff irq 16 at device 7.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:00:1b:2a:01 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x24e8000 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode atapci0: port 0x9400-0x943f, 0x9000-0x900f,0x8800-0x887f mem 0xfb500000-0xfb500fff, 0xfb400000-0xfb41ffff irq 18 at device 8.0 on pci0 atapci0: [ITHREAD] atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] em0: port 0x9800-0x983f mem 0xfb800000-0xfb81ffff,0xfb700000-0xfb71ffff irq 17 at device 12.0 on pci0 em0: Ethernet address: 00:0e:0c:ab:ad:42 em0: [FILTER] ahc0: port 0xa000-0xa0ff mem 0xfba00000-0xfba00fff irq 19 at device 14.0 on pci0 ahc0: [ITHREAD] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs atapci1: port 0xc000-0xc007,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xa800-0xa80f, 0xa400-0xa4ff irq 20 at device 15.0 on pci0 atapci1: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata0: [ITHREAD] ata1: on atapci2 ata1: [ITHREAD] uhci0: port 0xc400-0xc41f irq 21 at device 16.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 0xc800-0xc81f irq 21 at device 16.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 0xd000-0xd01f irq 21 at device 16.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 uhci3: port 0xd400-0xd41f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfbc00000-0xfbc000ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: waiting for BIOS to give up control usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered uhub5: on uhub4 uhub5: single transaction translator uhub5: 3 ports with 2 removable, self powered ukbd0: on uhub5 kbd2 at ukbd0 ums0: on uhub5 ums0: 5 buttons and Z dir. isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 4 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 4 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd0fff, 0xd1000-0xd1fff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub0 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master UDMA66 ad4: 476940MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 ad10: 114473MB at ata5-master SATA150 ad12: 152627MB at ata6-master SATA150 Waiting 5 seconds for SCSI devices to settle GEOM_MIRROR: Device mirror/gm2 launched (2/2). GEOM_MIRROR: Device mirror/gm1s1 launched (1/2). GEOM_MIRROR: Device gm1s1: rebuilding provider ad4s1. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sa0 at ahc0 bus 0 target 15 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 80.000MB/s transfers (40.000MHz, offset 32, 16bit) cd0 at ata0 bus 0 target 0 lun 0 cd0: LRaeumnocvhaebdl!e CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/mirror/gm2s1a WARNING: /home was not properly dismounted WARNING: /spare was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: /data was not properly dismounted kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=519104kB. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 21 18:57:08 2008 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 2669E106566B for ; Fri, 21 Mar 2008 18:57:08 +0000 (UTC) (envelope-from SRS0=b66fbc7b745a5bc036ac1f3448d6868353dfffb4=647=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 8480B8FC23 for ; Fri, 21 Mar 2008 18:57:07 +0000 (UTC) (envelope-from SRS0=b66fbc7b745a5bc036ac1f3448d6868353dfffb4=647=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id BVA25001; Fri, 21 Mar 2008 11:57:01 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3E3964500F; Fri, 21 Mar 2008 11:57:02 -0700 (PDT) To: Peter Jeremy In-Reply-To: Your message of "Fri, 21 Mar 2008 15:59:27 +1100." <20080321045927.GA85901@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1206125822_21153P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 21 Mar 2008 11:57:02 -0700 From: "Kevin Oberman" Message-Id: <20080321185702.3E3964500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Peter Jeremy X-To_Domain: optushome.com.au X-To: Peter Jeremy X-To_Email: peterjeremy@optushome.com.au X-To_Alias: peterjeremy Cc: Marko Lerota , freebsd-stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements 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, 21 Mar 2008 18:57:08 -0000 --==_Exmh_1206125822_21153P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Fri, 21 Mar 2008 15:59:27 +1100 > From: Peter Jeremy > Sender: owner-freebsd-stable@freebsd.org > > On Wed, Mar 19, 2008 at 07:43:25PM +0100, Marko Lerota wrote: > >time from ports because there are only small portion of precompiled > >packages. > > There should be a fairly complete set of packages for 7.0-RELEASE. > There can never be a totally complete set of packages for legal > reasons - the licenses on some ports do not permit them to be packaged. > > >This thing should be solved. > > Please offer some suggestions on how you would resolve the problem. > > >And If I upgrade the OS I dont want to recompile ports for that. > > You don't have to upgrade ports immediately. It's just that you can't > upgrade any single port without re-building everything - for reasons > that have been spelled out elsewhere in this thread. > > FWIW, the move to versioned symbols should (in theory) remove the > need to need to do a future complete recompile once you've rebuilt > all your ports against 7.x. My laptop has about 1000 ports installed and, when I did the mass upgrade a week or two ago. I did it a bit differently from most recommendations. I deleted all of the directories in /usr/local except etc and a coupe containing locally built and install software. This really cleans up any cruft from /usr/local. :-) Next, I manually installed lang/ruby18 and ports-mgmt/portupgrade and did a 'portupgrade -afP'. Since the pkgdb was still in place, it knew which ports had been installed before I nuked /usr/local. I only had to build one big, time consuming port, jdk16. I also had to re-build about 8 or 9 ports (postfix and several multimedia ports) for local config reasons. I ran it over night, starting up at "quitting time", and it finished the first pass early the next morning. I installed jdk15 from the diablo package and built jdk16. Then I upgraded the ports which were dependent on jdk16 (about a dozen) from packages. All in all, this worked rather well, although issuing all those 'rm -rf /usr/local/AAAA/*'s is very disconcerting. -- 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 --==_Exmh_1206125822_21153P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH5AT+kn3rs5h7N1ERAuL2AJ4uqW7fBJmUtrCM4Tmm1nnuMt8G2QCfSEzQ F75vlgif8Oson5p3VspySE4= =fDNQ -----END PGP SIGNATURE----- --==_Exmh_1206125822_21153P-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 03:52:12 2008 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 98B80106566B for ; Sat, 22 Mar 2008 03:52:12 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7228FC16 for ; Sat, 22 Mar 2008 03:52:12 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 48F681CC068; Fri, 21 Mar 2008 20:52:12 -0700 (PDT) Date: Fri, 21 Mar 2008 20:52:12 -0700 From: Jeremy Chadwick To: Gianni Doe Message-ID: <20080322035212.GA15541@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE 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, 22 Mar 2008 03:52:12 -0000 On Fri, Mar 21, 2008 at 06:27:19PM +0100, Gianni Doe wrote: > I'm also experiencing this issue after upgrading to 7.0-RELEASE from 6.3 The most I can provide is here: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 07:14:07 2008 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 899911065679 for ; Sat, 22 Mar 2008 07:14:07 +0000 (UTC) (envelope-from jpp@cloudview.com) Received: from skipjack.no-such-agency.net (skipjack.no-such-agency.net [64.142.114.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8298FC1A for ; Sat, 22 Mar 2008 07:14:07 +0000 (UTC) (envelope-from jpp@cloudview.com) Received: from skipjack.no-such-agency.net (localhost.sonic.net [127.0.0.1]) by skipjack.no-such-agency.net (Postfix) with ESMTP id F14161C043E for ; Sat, 22 Mar 2008 00:14:06 -0700 (PDT) Received: from jpp-desktop.localnet (gatekeeper.no-such-agency.net [64.142.103.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skipjack.no-such-agency.net (Postfix) with ESMTP id BC58E1C022C for ; Sat, 22 Mar 2008 00:14:06 -0700 (PDT) Message-ID: <47E4B1BC.6020005@cloudview.com> Date: Sat, 22 Mar 2008 00:14:04 -0700 From: John Pettitt User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 7-STABLE not seeing second em interface on supermicro mb 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, 22 Mar 2008 07:14:07 -0000 I just installed 7-STABLE on a new dual/quad machine based on a supermicro motherboard - it works fine except that it's not seeing the second network interface (em driver) - is there a magic incantation to make this work? FreeBSD echelon.localnet 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Mar 21 23:27:31 PDT 2008 root@echelon.localnet:/usr/src/sys/amd64/compile/ECHELON amd64 The only word from the em driver is this em0: port 0x3000-0x301f mem 0xde200000-0xde21ffff irq 17 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:64:d9:45 em0: [FILTER] ifconfig doesn't show anything other than em0 and lo0 Where should I start debugging this ? John From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 10:29:28 2008 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 C25671065677 for ; Sat, 22 Mar 2008 10:29:28 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: from mail.dataxnet.ro (datax28.mediasat.ro [80.96.28.28]) by mx1.freebsd.org (Postfix) with SMTP id 317988FC14 for ; Sat, 22 Mar 2008 10:29:19 +0000 (UTC) (envelope-from razor@dataxnet.ro) Received: (qmail 77340 invoked by uid 1001); 22 Mar 2008 12:29:33 +0200 Date: Sat, 22 Mar 2008 12:29:33 +0200 From: Alex Popa To: Max Laier Message-ID: <20080322102933.GA76747@dataxnet.ro> References: <20080314192359.GA4677@dataxnet.ro> <20080315203121.I42065@fledge.watson.org> <200803152217.02568.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <200803152217.02568.max@love2party.net> User-Agent: Mutt/1.4.2.2i Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces) 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, 22 Mar 2008 10:29:28 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry for the big delay, but here are the traces you requested. The kernel/world combination is from the same sources as in my previous posts, I've only changed the kernel config and recompiled it (wiped /usr/obj, make buildkernel && make installkernel in /usr/src). Note: I haven't had access to a serial console, and experimentation late last night showed me that kdb commands and their output don't get saved in dmesg... I was about to get a camera there in order to take photos of the backtraces and such, but I remembered vidcontrol and found the "-H -P" options to have some nice potential. Long story short, I added something like "options SC_HISTORY_SIZE=4000" to the kernel and here are the results. The dmesg file is an edited output of dmesg -a > something.txt, to only contain the actual LOR related parts. The first-lor and second-lor files contain edited screen captures (as made by vidcontrol), each of them with lots of debugging info for one of the two LORs. Sorry for some wrapped lines, but I hope that's better than nothing. Hope this helps Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-lor.txt" lock order reversal: 1st 0xffffffffa2a56680 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd 0xffffff00013236f0 radix node head (radix node head) @ /usr/src/sys/net/route.c:147 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x539 _mtx_lock_flags() at _mtx_lock_flags+0x1f rtalloc1() at rtalloc1+0x57 rtalloc_ign() at rtalloc_ign+0x8f pf_route() at pf_route+0x4d3 pf_test() at pf_test+0x64c pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0555d30, rbp = 0 --- KDB: enter: witness_checkorder exclusive sx so_rcv_sx r = 0 (0xffffff000140f3b8) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/src/sys/net/pfil.c:73 exclusive sleep mutex pf task mtx r = 0 (0xffffffffa2a56680) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/src/sys/net/pfil.c:73 Locked vnodes 0xffffff000144aba0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0001408000 (pid 36498) ino 2237440, on dev ufs/usr64 0xffffff00018905d0: tag ufs, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0001408000 (pid 36498) ino 2286392, on dev ufs/usr64 ... lock order reversal: 1st 0xffffffff8096eb88 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff8096f8a8 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:385 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x539 _mtx_lock_flags() at _mtx_lock_flags+0x1f udp_input() at udp_input+0x1f7 ip_input() at ip_input+0xa7 dummynet_send() at dummynet_send+0xde dummynet_io() at dummynet_io+0x587 ipfw_check_in() at ipfw_check_in+0x241 pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- KDB: enter: witness_checkorder exclusive sx so_rcv_sx r = 0 (0xffffff000140f3b8) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/src/sys/net/pfil.c:73 Locked vnodes 0xffffff001106a9b0: tag ufs, type VREG usecount 4, writecount 0, refcount 6 mountedhere 0 flags (VV_TEXT) v_object 0xffffff0011318680 ref 2 pages 35 lock type ufs: SHARED (count 1) ino 2239451, on dev ufs/usr64 0xffffff001106a3e0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0001820000 (pid 42488) ino 2262052, on dev ufs/usr64 0xffffff0001eabba0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff001106f680 (pid 42307) with 1 pending ino 2262734, on dev ufs/usr64 Starting background file system checks in 60 seconds. ... calcru: runtime went backwards from 3023 usec to 1678 usec for pid 36225 (dhcpd) --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="first-lor.txt" lock order reversal: 1st 0xffffffffa2a56680 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../. ./contrib/pf/net/pf.c:6729 2nd 0xffffff00013236f0 radix node head (radix node head) @ /usr/src/sys/net/rou te.c:147 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x539 _mtx_lock_flags() at _mtx_lock_flags+0x1f rtalloc1() at rtalloc1+0x57 rtalloc_ign() at rtalloc_ign+0x8f pf_route() at pf_route+0x4d3 pf_test() at pf_test+0x64c pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0555d30, rbp = 0 --- KDB: enter: witness_checkorder [thread pid 23 tid 100022 ] Stopped at kdb_enter+0x31: popq %rbp db> show pcpu cpuid = 0 curthread = 0xffffff00011bf340: pid 23 "em0 taskq" curpcb = 0xffffffffa0555d40 fpcurthread = none idlethread = 0xffffff000107f340: pid 12 "idle: cpu0" spin locks held: db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xffffff00011bf340: pid 23 "em0 taskq" curpcb = 0xffffffffa0555d40 fpcurthread = none idlethread = 0xffffff000107f340: pid 12 "idle: cpu0" spin locks held: cpuid = 1 curthread = 0xffffff00011bf000: pid 24 "em1 taskq" curpcb = 0xffffffffa057ad40 fpcurthread = none idlethread = 0xffffff000107f680: pid 11 "idle: cpu1" spin locks held: db> trace Tracing pid 23 tid 100022 td 0xffffff00011bf340 kdb_enter() at kdb_enter+0x31 witness_checkorder() at witness_checkorder+0x48e _mtx_lock_flags() at _mtx_lock_flags+0x1f rtalloc1() at rtalloc1+0x57 rtalloc_ign() at rtalloc_ign+0x8f pf_route() at pf_route+0x4d3 pf_test() at pf_test+0x64c pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0555d30, rbp = 0 --- db> alltrace Tracing command dhcpd pid 36121 tid 100080 td 0xffffff000146f680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec bwait() at bwait+0x55 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x2f7 vn_read() at vn_read+0x1d3 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800772acc, rsp = 0x7fffffffeba8, r bp = 0xcc5c --- Tracing command sh pid 35283 tid 100064 td 0xffffff0001420680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800923abc, rsp = 0x7fffffffd2c8, rbp = 0x33 --- Tracing command ntpd pid 34406 tid 100076 td 0xffffff00014b4680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba kern_kevent() at kern_kevent+0x36a kevent() at kevent+0x85 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800bd531c, rsp = 0x7fffffffcc0 8, rbp = 0xf --- Tracing command named pid 29869 tid 100102 td 0xffffff0001426340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c03a4c, rsp = 0x7fffff5fbcc8 , rbp = 0x26 --- Tracing command named pid 29869 tid 100101 td 0xffffff0001426680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba do_cv_wait() at do_cv_wait+0x312 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffff7fc dc8, rbp = 0x7fffff7fce30 --- Tracing command named pid 29869 tid 100100 td 0xffffff00014269c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa do_cv_wait() at do_cv_wait+0x4c2 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffff9fd eb8, rbp = 0 --- Tracing command named pid 29869 tid 100099 td 0xffffff0001420000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa do_cv_wait() at do_cv_wait+0x4c2 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffffbfe eb8, rbp = 0 --- Tracing command named pid 29869 tid 100075 td 0xffffff00014b49c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_sigtimedwait() at kern_sigtimedwait+0x4ea sigwait() at sigwait+0x63 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x800b7dc6c, rsp = 0x7fffffffec 48, rbp = 0x800e01120 --- Tracing command syslogd pid 26784 tid 100091 td 0xffffff00017bd000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80081aa4c, rsp = 0x7fffffffdda8 , rbp = 0x800a1c0f0 --- Tracing command accounting pid 24352 tid 100087 td 0xffffff00017be000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 acct_thread() at acct_thread+0x1c3 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa2a66d30, rbp = 0 --- Tracing command devd pid 22944 tid 100060 td 0xffffff000140a000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x43796c, rsp = 0x7fffffffe928, r bp = 0x7fffffffed50 --- Tracing command pflogd pid 14667 tid 100063 td 0xffffff00014209c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba bpfread() at bpfread+0xde devfs_read_f() at devfs_read_f+0x67 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800940acc, rsp = 0x7fffffffed08, r bp = 0x1 --- Tracing command pflogd pid 14530 tid 100066 td 0xffffff0001404340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa soreceive_generic() at soreceive_generic+0xd1a dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800940acc, rsp = 0x7fffffffe938, r bp = 0x4 --- Tracing command pfpurge pid 14486 tid 100062 td 0xffffff0001404680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 pf_purge_thread() at pf_purge_thread+0x60 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa29c2d30, rbp = 0 --- Tracing command sh pid 51 tid 100050 td 0xffffff0001353680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800923abc, rsp = 0x7fffffffe6d8, rbp = 0x33 --- Tracing command schedcpu pid 50 tid 100049 td 0xffffff00013539c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 schedcpu_thread() at schedcpu_thread+0x209 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa067ed30, rbp = 0 --- Tracing command softdepflush pid 49 tid 100048 td 0xffffff0001355000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 softdep_flush() at softdep_flush+0x2da fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0679d30, rbp = 0 --- Tracing command syncer pid 48 tid 100047 td 0xffffff0001355340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec sched_sync() at sched_sync+0x5da fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0674d30, rbp = 0 --- Tracing command vnlru pid 47 tid 100046 td 0xffffff0001355680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vnlru_proc() at vnlru_proc+0x692 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa066fd30, rbp = 0 --- Tracing command bufdaemon pid 46 tid 100045 td 0xffffff00013559c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 buf_daemon() at buf_daemon+0x225 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa066ad30, rbp = 0 --- Tracing command pagezero pid 45 tid 100044 td 0xffffff00012479c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vm_pagezero() at vm_pagezero+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0665d30, rbp = 0 --- Tracing command vmdaemon pid 44 tid 100043 td 0xffffff0001298000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0660d30, rbp = 0 --- Tracing command pagedaemon pid 43 tid 100042 td 0xffffff0001298340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vm_pageout() at vm_pageout+0xa62 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa065bd30, rbp = 0 --- Tracing command dummynet pid 42 tid 100041 td 0xffffff0001298680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 msleep_spin() at msleep_spin+0x18f taskqueue_thread_loop() at taskqueue_thread_loop+0x45 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0656d30, rbp = 0 --- Tracing command irq1: atkbd0 pid 41 tid 100040 td 0xffffff00012989c0 fork_trampoline() at fork_trampoline Tracing command irq7: ppbus0 ppc0 pid 40 tid 100039 td 0xffffff0001299000 fork_trampoline() at fork_trampoline Tracing command swi0: sio pid 39 tid 100038 td 0xffffff0001299340 fork_trampoline() at fork_trampoline Tracing command fdc0 pid 38 tid 100037 td 0xffffff0001299680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 fdc_thread() at fdc_thread+0x7b5 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0622d30, rbp = 0 --- Tracing command irq15: ata1 pid 37 tid 100036 td 0xffffff00012999c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0613d30, rbp = 0 --- Tracing command irq14: ata0 pid 36 tid 100035 td 0xffffff000129b000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05fbd30, rbp = 0 --- Tracing command usb4 pid 35 tid 100034 td 0xffffff00011c0680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05e3d30, rbp = 0 --- Tracing command usb3 pid 34 tid 100033 td 0xffffff00011c09c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05ccd30, rbp = 0 --- Tracing command irq16: uhci3 pid 33 tid 100032 td 0xffffff0001246000 fork_trampoline() at fork_trampoline Tracing command usb2 pid 32 tid 100031 td 0xffffff0001246340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05c1d30, rbp = 0 --- Tracing command usb1 pid 31 tid 100030 td 0xffffff0001246680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05bbd30, rbp = 0 --- Tracing command irq19: uhci1 pid 30 tid 100029 td 0xffffff00012469c0 fork_trampoline() at fork_trampoline Tracing command usbtask-dr pid 29 tid 100028 td 0xffffff0001247000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec usb_task_thread() at usb_task_thread+0x99 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05b0d30, rbp = 0 --- Tracing command usbtask-hc pid 28 tid 100027 td 0xffffff0001247340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec usb_task_thread() at usb_task_thread+0x99 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05abd30, rbp = 0 --- Tracing command usb0 pid 27 tid 100026 td 0xffffff0001247680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05a6d30, rbp = 0 --- Tracing command irq23: uhci0 ehci0 pid 26 tid 100025 td 0xffffff00011a6680 fork_trampoline() at fork_trampoline Tracing command irq18: bge0 uhci2 pid 25 tid 100024 td 0xffffff00011a69c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa059bd30, rbp = 0 --- Tracing command em1 taskq pid 24 tid 100023 td 0xffffff00011bf000 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x32 trap() at trap+0x2fd nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8040984d, rsp = 0xffffffff9fe19ff0, rbp = 0xfffff fffa057a870 --- _mtx_lock_sleep() at _mtx_lock_sleep+0xe0 _mtx_lock_flags() at _mtx_lock_flags+0x7a pf_test() at pf_test+0x72 pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- Tracing command em0 taskq pid 23 tid 100022 td 0xffffff00011bf340 kdb_enter() at kdb_enter+0x31 witness_checkorder() at witness_checkorder+0x48e _mtx_lock_flags() at _mtx_lock_flags+0x1f rtalloc1() at rtalloc1+0x57 rtalloc_ign() at rtalloc_ign+0x8f pf_route() at pf_route+0x4d3 pf_test() at pf_test+0x64c pf_check_in() at pf_check_in+0x2b pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0555d30, rbp = 0 --- Tracing command irq9: acpi0 pid 22 tid 100021 td 0xffffff00011bf680 fork_trampoline() at fork_trampoline Tracing command kqueue taskq pid 21 tid 100020 td 0xffffff00011bf9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa052bd30, rbp = 0 --- Tracing command swi6: task queue pid 20 tid 100019 td 0xffffff00011c0000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0526d30, rbp = 0 --- Tracing command swi6: Giant taskq pid 19 tid 100018 td 0xffffff00011c0340 fork_trampoline() at fork_trampoline Tracing command thread taskq pid 9 tid 100017 td 0xffffff000108c9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa051cd30, rbp = 0 --- Tracing command swi5: + pid 18 tid 100016 td 0xffffff00011a5000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0517d30, rbp = 0 --- Tracing command swi2: cambio pid 17 tid 100015 td 0xffffff00011a5340 fork_trampoline() at fork_trampoline Tracing command xpt_thrd pid 8 tid 100014 td 0xffffff00011a5680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec xpt_scanner_thread() at xpt_scanner_thread+0x38 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa050dd30, rbp = 0 --- Tracing command acpi_task_2 pid 7 tid 100013 td 0xffffff00011a59c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0508d30, rbp = 0 --- Tracing command acpi_task_1 pid 6 tid 100012 td 0xffffff00011a6000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0503d30, rbp = 0 --- Tracing command acpi_task_0 pid 5 tid 100011 td 0xffffff00011a6340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04fed30, rbp = 0 --- Tracing command yarrow pid 16 tid 100010 td 0xffffff0001080340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 random_kthread() at random_kthread+0x1a4 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04f5d30, rbp = 0 --- Tracing command g_down pid 4 tid 100009 td 0xffffff0001080680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_io_schedule_down() at g_io_schedule_down+0x201 g_down_procbody() at g_down_procbody+0x55 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04f0d30, rbp = 0 --- Tracing command g_up pid 3 tid 100008 td 0xffffff00010809c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_io_schedule_up() at g_io_schedule_up+0x119 g_up_procbody() at g_up_procbody+0x55 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04ebd30, rbp = 0 --- Tracing command g_event pid 2 tid 100007 td 0xffffff000108c000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_event_procbody() at g_event_procbody+0xa9 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04e6d30, rbp = 0 --- Tracing command swi3: vm pid 15 tid 100006 td 0xffffff000108c340 fork_trampoline() at fork_trampoline Tracing command swi4: clock sio pid 14 tid 100005 td 0xffffff000108c680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04dcd30, rbp = 0 --- Tracing command swi1: net pid 13 tid 100004 td 0xffffff000107f000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04d7d30, rbp = 0 --- Tracing command idle: cpu0 pid 12 tid 100003 td 0xffffff000107f340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 critical_exit() at critical_exit+0x83 intr_execute_handlers() at intr_execute_handlers+0xdd Xapic_isr1() at Xapic_isr1+0x7f --- interrupt, rip = 0xffffffff805ce6a2, rsp = 0xffffffffa04d1bc0, rbp = 0xfffff fffa04d1bd0 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x19a sched_idletd() at sched_idletd+0x64 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04d1d30, rbp = 0 --- Tracing command idle: cpu1 pid 11 tid 100002 td 0xffffff000107f680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 critical_exit() at critical_exit+0x83 intr_execute_handlers() at intr_execute_handlers+0xdd Xapic_isr1() at Xapic_isr1+0x7f --- interrupt, rip = 0xffffffff805ce6a2, rsp = 0xffffffffa04ccbc0, rbp = 0xfffff fffa04ccbd0 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x19a sched_idletd() at sched_idletd+0x64 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04ccd30, rbp = 0 --- Tracing command init pid 1 tid 100001 td 0xffffff000107f9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40b61c, rsp = 0x7fffffffe848, rbp = 0x33 --- Tracing command audit pid 10 tid 100000 td 0xffffff0001080000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _cv_wait() at _cv_wait+0x115 audit_worker() at audit_worker+0x47f fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04c2d30, rbp = 0 --- Tracing command swapper pid 0 tid 0 td 0xffffffff808def70 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 scheduler() at scheduler+0x39e mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> show alllocks Process 14530 (pflogd) thread 0xffffff0001404340 (100066) exclusive sx so_rcv_sx r = 0 (0xffffff00014713b8) locked @ /usr/src/sys/kern/uip c_sockbuf.c:148 Process 24 (em1 taskq) thread 0xffffff00011bf000 (100023) shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/sr c/sys/net/pfil.c:73 Process 23 (em0 taskq) thread 0xffffff00011bf340 (100022) exclusive sleep mutex pf task mtx r = 0 (0xffffffffa2a56680) locked @ /usr/src/s ys/modules/pf/../../contrib/pf/net/pf.c:6729 shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/sr c/sys/net/pfil.c:73 db> show witness Sleep locks: 0 so_rcv_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 7 so_rcv -- last acquired @ /usr/src/sys/kern/uipc_socket.c:2022 8 sellck -- last acquired @ /usr/src/sys/kern/sys_generic.c:759 8 radix node head -- last acquired @ /usr/src/sys/net/route.c:147 9 rtentry -- last acquired @ /usr/src/sys/netinet/ip_output.c:594 10 ifaddr -- last acquired @ /usr/src/sys/net/route.c:287 10 rts_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 11 UMA zone -- last acquired @ /usr/src/sys/vm/uma_core.c:2335 11 UMA zone -- (already displayed) 9 UMA boot pages -- last acquired @ /usr/src/sys/vm/uma_core.c:916 11 vm page queue free mutex -- last acquired @ /usr/src/sys/vm/vm_page.c:1030 9 ifnet -- last acquired @ /usr/src/sys/net/if.c:1047 11 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:212 12 eventhandler list -- last acquired @ /usr/src/sys/kern/kern_exec.c:904 10 if_addr_mtx -- last acquired @ /usr/src/sys/net/if.c:828 10 pf task mtx -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/ne t/pf.c:6729 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 11 arc4_mtx -- last acquired @ /usr/src/sys/libkern/arc4random.c:137 11 bpf interface lock -- last acquired @ /usr/src/sys/net/bpf.c:1422 12 bpf cdev lock -- last acquired @ /usr/src/sys/net/bpf.c:1426 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 8 process lock -- last acquired @ /usr/src/sys/amd64/amd64/trap.c:622 9 session -- last acquired @ /usr/src/sys/kern/kern_fork.c:582 10 uidinfo hash -- last acquired @ /usr/src/sys/kern/kern_resource.c:1213 11 uidinfo struct -- last acquired @ order list:0 11 sleep mtxpool -- last acquired @ /usr/src/sys/kern/vfs_vnops.c:508 12 kqueue -- last acquired @ /usr/src/sys/kern/kern_event.c:1182 13 struct mount mtx -- last acquired @ /usr/src/sys/kern/vfs_mount.c:440 14 vnode interlock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:2621 15 cdev -- last acquired @ /usr/src/sys/kern/kern_conf.c:69 15 vnode_free_list -- last acquired @ /usr/src/sys/kern/vfs_subr.c:3040 15 Syncer mtx -- last acquired @ /usr/src/sys/kern/vfs_subr.c:1915 10 tty -- last acquired @ /usr/src/sys/kern/kern_event.c:1664 9 sigacts -- last acquired @ /usr/src/sys/kern/subr_sleepqueue.c:392 9 ktrace -- last acquired @ /usr/src/sys/kern/kern_fork.c:600 11 sleep mtxpool -- (already displayed) 11 sleep mtxpool -- (already displayed) 11 UMA zone -- (already displayed) 12 kqueue -- (already displayed) 8 process lock -- (already displayed) 2 unp_mtx -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:803 3 accept -- last acquired @ /usr/src/sys/kern/uipc_socket.c:2837 6 so_snd -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:234 7 so_rcv -- (already displayed) 11 sleep mtxpool -- (already displayed) 7 so_rcv -- (already displayed) 7 so_rcv -- (already displayed) 6 so_snd -- (already displayed) 3 filedesc structure -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1987 14 vnode interlock -- (already displayed) 8 process lock -- (already displayed) 11 sleep mtxpool -- (already displayed) 5 Name Cache -- last acquired @ /usr/src/sys/kern/vfs_cache.c:327 14 vnode interlock -- (already displayed) 11 UMA zone -- (already displayed) 9 UMA boot pages -- (already displayed) 4 fdesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1472 15 cdev -- (already displayed) 4 Giant -- last acquired @ /usr/src/sys/kern/kern_timeout.c:241 5 pipe mutex -- last acquired @ /usr/src/sys/kern/sys_pipe.c:1331 6 sigio lock -- last acquired @ /usr/src/sys/kern/kern_descrip.c:782 7 process group -- last acquired @ /usr/src/sys/kern/kern_fork.c:572 8 process lock -- (already displayed) 8 sellck -- (already displayed) 11 UMA zone -- (already displayed) 6 system map -- last acquired @ /usr/src/sys/kern/vfs_bio.c:1995 8 vm page queue mutex -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3437 14 vnode interlock -- (already displayed) 9 pmap -- last acquired @ /usr/src/sys/amd64/amd64/pmap.c:3076 11 vm page queue free mutex -- (already displayed) 11 vm page queue free mutex -- (already displayed) 7 kmem object -- last acquired @ /usr/src/sys/vm/vm_object.c:441 11 vm page queue free mutex -- (already displayed) 8 vm page queue mutex -- (already displayed) 7 kernel object -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3641 11 vm page queue free mutex -- (already displayed) 8 vm page queue mutex -- (already displayed) 11 vm page queue free mutex -- (already displayed) 9 pmap -- (already displayed) 7 KMAP ENTRY -- last acquired @ /usr/src/sys/vm/uma_core.c:2905 11 UMA zone -- (already displayed) 7 standard object -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3426 11 vm page queue free mutex -- (already displayed) 14 vnode interlock -- (already displayed) 8 vm page queue mutex -- (already displayed) 8 vm object_list -- last acquired @ /usr/src/sys/vm/vm_object.c:225 11 UMA zone -- (already displayed) 5 UMA lock -- last acquired @ /usr/src/sys/vm/uma_core.c:1314 11 UMA zone -- (already displayed) 7 KMAP ENTRY -- (already displayed) 9 UMA boot pages -- (already displayed) 11 vm page queue free mutex -- (already displayed) 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 5 kobj -- last acquired @ /usr/src/sys/kern/subr_kobj.c:307 6 kernel environment -- last acquired @ /usr/src/sys/kern/kern_environment.c: 301 7 kernel object -- (already displayed) 8 vm object_list -- (already displayed) 7 KMAP ENTRY -- (already displayed) 10 uidinfo hash -- (already displayed) 8 process lock -- (already displayed) 11 sleep mtxpool -- (already displayed) 5 evclass_mtx -- last acquired @ /usr/src/sys/security/audit/audit_bsm_klib.c :112 5 TID lock -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 7 standard object -- (already displayed) 5 intr event -- last acquired @ /usr/src/sys/kern/kern_intr.c:454 15 cdev -- (already displayed) 5 GEOM orphanage -- last acquired @ /usr/src/sys/geom/geom_event.c:201 5 ttylist -- last acquired @ /usr/src/sys/kern/tty.c:3126 10 tty -- (already displayed) 5 intr config -- last acquired @ /usr/src/sys/kern/subr_autoconf.c:73 5 taskqueue list -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:125 5 XPT lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:2668 6 XPT topology lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:2673 6 kernel environment -- (already displayed) 7 taskqueue -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:73 5 rman head -- last acquired @ /usr/src/sys/kern/subr_rman.c:152 5 rman -- last acquired @ /usr/src/sys/kern/subr_rman.c:539 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 5 devd -- last acquired @ /usr/src/sys/kern/subr_bus.c:489 8 sellck -- (already displayed) 8 sellck -- (already displayed) 5 ACPI semaphore -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdSynch.c:30 3 5 acpi subsystem HW lock -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdSy nch.c:377 5 acpi subsystem GPE lock -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdS ynch.c:377 7 taskqueue -- (already displayed) 5 msi -- last acquired @ /usr/src/sys/amd64/amd64/msi.c:389 9 ifnet -- (already displayed) 5 bpf global lock -- last acquired @ /usr/src/sys/net/bpf.c:1671 11 bpf interface lock -- (already displayed) 5 bounce pages lock -- last acquired @ /usr/src/sys/amd64/amd64/busdma_machde p.c:1073 9 pmap -- (already displayed) 5 unit# allocation -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 15 vnode_free_list -- (already displayed) 5 pfs_node -- last acquired @ /usr/src/sys/fs/pseudofs/pseudofs_internal.h:10 3 5 pfs_fileno -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 5 random reseed -- last acquired @ /usr/src/sys/dev/random/yarrow.c:278 11 arc4_mtx -- (already displayed) 5 nfsd_mtx -- last acquired @ /usr/src/sys/nfsserver/nfs_srvsock.c:796 6 so_snd -- (already displayed) 5 if_clone lock -- last acquired @ /usr/src/sys/net/if_clone.c:164 5 if_cloners lock -- last acquired @ /usr/src/sys/net/if_clone.c:252 5 domain list -- last acquired @ /usr/src/sys/kern/uipc_domain.c:228 6 pfil_head_list lock -- last acquired @ /usr/src/sys/net/pfil.c:159 5 PFil hook read/write mutex -- last acquired @ /usr/src/sys/net/pfil.c:73 6 pfil_head_list lock -- (already displayed) 10 pf task mtx -- (already displayed) 6 IPFW static rules -- last acquired @ /usr/src/sys/netinet/ip_fw2.c:2647 8 radix node head -- (already displayed) 7 if send queue -- last acquired @ /usr/src/sys/dev/em/if_em.c:949 6 network driver -- last acquired @ /usr/src/sys/dev/bge/if_bge.c:3014 10 if_addr_mtx -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 7 taskqueue -- (already displayed) 7 if send queue -- (already displayed) 5 isn_mtx -- last acquired @ /usr/src/sys/netinet/tcp_subr.c:1426 8 radix node head -- (already displayed) 6 IPFW static rules -- (already displayed) 5 lo_mtx -- last acquired @ /usr/src/sys/net/if_loop.c:161 5 ATA queue lock -- last acquired @ /usr/src/sys/dev/ata/ata-queue.c:177 6 ATA state lock -- last acquired @ /usr/src/sys/dev/ata/ata-queue.c:194 5 devstat -- last acquired @ /usr/src/sys/kern/subr_devstat.c:83 6 XPT topology lock -- (already displayed) 5 NFS iod lock -- last acquired @ /usr/src/sys/nfsclient/nfs_nfsiod.c:196 6 mountlist -- last acquired @ /usr/src/sys/kern/vfs_syscalls.c:526 13 struct mount mtx -- (already displayed) 13 struct mount mtx -- (already displayed) 5 mntid -- last acquired @ /usr/src/sys/kern/vfs_subr.c:460 6 mountlist -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:1738 14 vnode interlock -- (already displayed) 5 bio queue -- last acquired @ /usr/src/sys/geom/geom_io.c:68 5 bdone lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3800 5 needsbuffer lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:321 5 FFS Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_alloc.c:1475 11 arc4_mtx -- (already displayed) 5 Name Cache -- (already displayed) 5 knlist lock for lockless objects -- last acquired @ /usr/src/sys/kern/kern_ event.c:1664 5 vfs hash -- last acquired @ /usr/src/sys/kern/vfs_hash.c:71 14 vnode interlock -- (already displayed) 5 devfs interlock -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:194 14 vnode interlock -- (already displayed) 5 dirhash list -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:349 6 dirhash -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:457 6 dirhash -- (already displayed) 5 pbuf mutex -- last acquired @ /usr/src/sys/vm/vm_pager.c:413 8 vm page queue mutex -- (already displayed) 7 process group -- (already displayed) 10 tty -- (already displayed) 9 session -- (already displayed) 5 Softdep Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_softdep.c:5022 6 system map -- (already displayed) 11 UMA zone -- (already displayed) 14 vnode interlock -- (already displayed) 6 buffer daemon lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:429 10 pf task mtx -- (already displayed) 6 buffer daemon lock -- (already displayed) 6 sigio lock -- (already displayed) 6 so_snd -- (already displayed) 5 pipe mutex -- (already displayed) 0 so_snd_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 6 so_snd -- (already displayed) 1 unp_global_rwlock -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:770 2 unp_mtx -- (already displayed) 3 filedesc structure -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 8 radix node head -- (already displayed) 9 rtentry -- (already displayed) 10 rts_inq -- (already displayed) 0 pf_statetbl_lock -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/n et/pf.c:979 10 pf task mtx -- (already displayed) 6 pfil_head_list lock -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 0 devfsmount -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 5 devfs interlock -- (already displayed) 15 vnode_free_list -- (already displayed) 14 vnode interlock -- (already displayed) 13 struct mount mtx -- (already displayed) 15 cdev -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 1 DEVFS ruleset lock -- last acquired @ /usr/src/sys/fs/devfs/devfs_rule.c:177 0 g_disk_done -- last acquired @ /usr/src/sys/geom/geom_disk.c:198 5 bio queue -- (already displayed) 11 UMA zone -- (already displayed) 0 dummynet -- last acquired @ /usr/src/sys/netinet/ip_dummynet.c:739 0 ipqlock -- last acquired @ /usr/src/sys/netinet/ip_input.c:1086 0 sem -- last acquired @ /usr/src/sys/kern/sysv_sem.c:1288 0 fdc lock -- last acquired @ /usr/src/sys/dev/fdc/fdc.c:803 0 if_afdata -- last acquired @ /usr/src/sys/net/if.c:578 0 GEOM topology -- last acquired @ /usr/src/sys/geom/geom_event.c:233 5 GEOM orphanage -- (already displayed) 5 devstat -- (already displayed) 5 unit# allocation -- (already displayed) 15 cdev -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 9 UMA boot pages -- (already displayed) 8 vm object_list -- (already displayed) 14 vnode interlock -- (already displayed) 7 standard object -- (already displayed) 6 system map -- (already displayed) 0 intr sources -- last acquired @ /usr/src/sys/amd64/amd64/intr_machdep.c:593 5 msi -- (already displayed) 0 audit_mtx -- last acquired @ /usr/src/sys/security/audit/audit_worker.c:448 0 uma object -- last acquired @ /usr/src/sys/vm/vm_meter.c:115 0 p_peers -- last acquired @ /usr/src/sys/kern/kern_exit.c:284 0 runningbufspace lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:340 0 umtxql -- last acquired @ /usr/src/sys/kern/kern_umtx.c:326 0 accept_filter_mtx -- last acquired @ /usr/src/sys/kern/uipc_accf.c:116 0 clone events drain lock -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c :626 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 15 cdev -- (already displayed) 0 ACPI PCI bus methods -- last acquired @ /usr/src/sys/dev/acpica/acpi_pcib.c:22 1 0 rtsock route_cb lock -- last acquired @ /usr/src/sys/net/rtsock.c:236 0 rawcb -- last acquired @ /usr/src/sys/net/raw_cb.c:104 7 so_rcv -- (already displayed) 11 UMA zone -- (already displayed) 0 ACPI PCI link -- last acquired @ /usr/src/sys/dev/acpica/acpi_pci_link.c:432 5 ACPI semaphore -- (already displayed) 0 ACPI root bus -- last acquired @ /usr/src/sys/dev/acpica/acpi.c:1022 5 rman -- (already displayed) 5 ACPI semaphore -- (already displayed) 6 system map -- (already displayed) 0 acct_sx -- last acquired @ /usr/src/sys/kern/kern_acct.c:351 11 eventhandler -- (already displayed) 1 proctree -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:325 2 allproc -- last acquired @ /usr/src/sys/kern/kern_fork.c:297 3 allprison -- last acquired @ /usr/src/sys/kern/kern_jail.c:945 11 sleep mtxpool -- (already displayed) 8 process lock -- (already displayed) 4 fdesc -- (already displayed) 3 filedesc structure -- (already displayed) 14 vnode interlock -- (already displayed) 3 user map -- last acquired @ /usr/src/sys/vm/vm_map.c:3111 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 8 vm object_list -- (already displayed) 7 standard object -- (already displayed) 8 vm page queue mutex -- (already displayed) 9 UMA boot pages -- (already displayed) 9 pmap -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- (already displayed) 5 needsbuffer lock -- (already displayed) 6 system map -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 13 struct mount mtx -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 Softdep Lock -- (already displayed) 11 arc4_mtx -- (already displayed) 7 process group -- (already displayed) 4 Giant -- (already displayed) 8 process lock -- (already displayed) 9 session -- (already displayed) 6 sigio lock -- (already displayed) 3 filedesc structure -- (already displayed) 8 process lock -- (already displayed) 5 FFS Lock -- (already displayed) 13 struct mount mtx -- (already displayed) 14 vnode interlock -- (already displayed) 7 standard object -- (already displayed) 5 buf queue lock -- (already displayed) 6 system map -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 4 Giant -- (already displayed) 5 needsbuffer lock -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 Softdep Lock -- (already displayed) 0 vm daemon -- last acquired @ /usr/src/sys/vm/vm_pageout.c:1531 0 protect sysfilt_ops -- last acquired @ /usr/src/sys/kern/kern_event.c:758 0 so_glabel -- last acquired @ /usr/src/sys/kern/uipc_socket.c:280 0 sysctl lock -- last acquired @ /usr/src/sys/kern/kern_sysctl.c:1396 11 arc4_mtx -- (already displayed) 2 allproc -- (already displayed) 8 process lock -- (already displayed) 3 user map -- (already displayed) 15 cdev -- (already displayed) 1 filelist lock -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1366 3 filedesc structure -- (already displayed) 5 GEOM orphanage -- (already displayed) 4 Giant -- (already displayed) 9 ktrace -- (already displayed) 1 kernel linker -- last acquired @ /usr/src/sys/kern/kern_linker.c:1096 11 UMA zone -- (already displayed) 2 module subsystem sx lock -- last acquired @ /usr/src/sys/kern/kern_module.c: 407 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 3 filedesc structure -- (already displayed) 14 vnode interlock -- (already displayed) 5 Name Cache -- (already displayed) 5 buf queue lock -- (already displayed) 5 needsbuffer lock -- (already displayed) 5 vfs hash -- (already displayed) 15 vnode_free_list -- (already displayed) 13 struct mount mtx -- (already displayed) 5 dirhash list -- (already displayed) 11 vm page queue free mutex -- (already displayed) 6 system map -- (already displayed) 7 kernel object -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 6 dirhash -- (already displayed) 15 cdev -- (already displayed) 8 vm object_list -- (already displayed) 7 standard object -- (already displayed) 5 pbuf mutex -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 kobj -- (already displayed) 1 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:741 11 UMA zone -- (already displayed) 6 system map -- (already displayed) 5 devstat -- (already displayed) 5 ttylist -- (already displayed) 8 vm object_list -- (already displayed) 5 UMA lock -- (already displayed) 15 Syncer mtx -- (already displayed) 1 unp_global_rwlock -- (already displayed) 1 tcp -- last acquired @ /usr/src/sys/netinet/tcp_usrreq.c:254 2 tcpinp -- last acquired @ /usr/src/sys/netinet/tcp_usrreq.c:255 6 so_snd -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 7 so_rcv -- (already displayed) 9 ifnet -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 1 tcp_sc_head -- last acquired @ /usr/src/sys/netinet/tcp_syncache.c:1696 1 udp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:839 2 udpinp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:843 3 in_multi_mtx -- last acquired @ /usr/src/sys/netinet/in_mcast.c:320 4 igmp_mtx -- last acquired @ /usr/src/sys/netinet/igmp.c:446 10 if_addr_mtx -- (already displayed) 10 if_addr_mtx -- (already displayed) 4 EM Core Lock -- last acquired @ /usr/src/sys/kern/kern_timeout.c:241 5 EM TX Lock -- last acquired @ /usr/src/sys/dev/em/if_em.c:1563 7 if send queue -- (already displayed) 10 if_addr_mtx -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 9 UMA boot pages -- (already displayed) 7 taskqueue -- (already displayed) 6 network driver -- (already displayed) 6 so_snd -- (already displayed) 9 ifnet -- (already displayed) 11 arc4_mtx -- (already displayed) 8 radix node head -- (already displayed) 9 rtentry -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 5 EM TX Lock -- (already displayed) 7 so_rcv -- (already displayed) 3 accept -- (already displayed) 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 9 UMA boot pages -- (already displayed) 8 radix node head -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 9 rtentry -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 5 EM TX Lock -- (already displayed) 1 rip -- last acquired @ /usr/src/sys/netinet/raw_ip.c:613 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 2 rawinp -- last acquired @ /usr/src/sys/netinet/in_pcb.c:221 5 ACPI semaphore -- (already displayed) 3 allprison -- (already displayed) 1 cpufreq lock -- last acquired @ /usr/src/sys/kern/kern_cpu.c:413 11 UMA zone -- (already displayed) 11 vm page queue free mutex -- (already displayed) 9 UMA boot pages -- (already displayed) 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 9 ifnet -- (already displayed) 1 ACPI CPU -- last acquired @ /usr/src/sys/dev/acpica/acpi_cpu.c:1167 0 ng_node -- last acquired @ order list:0 1 ng_worklist -- last acquired @ order list:0 0 802.11 com lock -- last acquired @ order list:0 0 ddp_list_mtx -- last acquired @ order list:0 1 ddp_mtx -- last acquired @ order list:0 0 slip_mtx -- last acquired @ order list:0 1 slip sc_mtx -- last acquired @ order list:0 0 unp -- last acquired @ order list:0 6 so_snd -- (already displayed) Spin locks: Locks which were never acquired: swap_pager swhash SCSI CD Changer List MD config lock IPFW dynamic rules arp_inq tcp_hc_entry ip_inq pfs_vncache ppp_softc_list_mtx tunmtx gif_mtx msq semid nfs4dev state nfs4dev waitq nfs4dev newq ntfs nthash NFS xid lock NFS reqq lock ACPI global lock CAM SIMQ lock hptlock LED sx LED mtx audit_pipe_mtx nfslock audit_trigger_mtx ktrace_sx bpin lock UUID generator mutex lock ACPI PCI power methods ACPI lid ACPI HPET support ACPI embedded controller ACPI thermal zone ACPI Smart Battery ACPI cmbat ACPI power resources ACPI generic battery ACPI AC adapter MSDOSFS fileno pmc shared lock kqueue order firmware table securelevel mutex lock encapmtx fifo mutex phys_pager list dev_pager list swapdev swap_pager list vm map sleep mutex db> show lockedvnods Locked vnodes 0xffffff0001906000: tag ufs, type VREG usecount 1, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xffffff00018714e0 ref 0 pages 13 lock type ufs: SHARED (count 1) ino 2240130, on dev ufs/usr64 db> show uma Zone Size Used Free Requests pfosfp 40 407 97 407 pfospfen 112 696 30 696 pfiaddrpl 120 0 0 0 pfstatescrub 40 0 0 0 pffrcent 24 0 0 0 pffrcache 80 0 0 0 pffrag 80 0 0 0 pffrent 32 0 0 0 pfrkentry2 216 0 0 0 pfrkentry 216 470 52 478 pfrktable 1296 12 27 28 pfpooladdrpl 88 12 72 12 pfaltqpl 240 0 0 0 pfstatepl 392 12 18 12 pfrulepl 912 69 15 69 pfsrctrpl 152 0 0 0 FFS2 dinode 256 426 39 435 FFS1 dinode 128 0 0 0 FFS inode 192 426 34 435 Mountpoints 808 6 9 6 SWAPMETA 288 0 0 0 IPFW dynamic rule 120 0 0 0 rtentry 240 24 40 26 ripcb 288 1 25 1 sackhole 32 0 0 0 tcpreass 40 0 0 0 hostcache 136 0 0 0 syncache 120 0 0 0 tcptw 88 0 0 0 tcpcb 728 9 16 11 inpcb 288 9 30 11 udpcb 288 20 32 717 ipq 56 0 0 0 unpcb 248 10 35 16 socket 696 40 15 747 KNOTE 120 2 60 2 itimer 360 0 0 0 ksiginfo 112 58 998 58 pipe 744 1 39 495 NFSNODE 664 0 0 0 NFSMOUNT 568 0 0 0 DIRHASH 1024 37 11 37 NAMEI 1024 0 36 6609 L VFS Cache 327 0 0 0 S VFS Cache 104 427 41 903 VNODEPOLL 128 0 0 0 VNODE 496 452 44 462 ata_composite 352 0 0 0 ata_request 312 1 83 1218 g_bio 216 5 355 6008 ACL UMA zone 388 0 0 0 mbuf_ext_refcnt 4 0 0 0 mbuf_jumbo_16k 16384 0 0 0 mbuf_jumbo_9k 9216 0 0 0 mbuf_jumbo_pagesize 4096 0 0 0 mbuf_cluster 2048 1024 8 1024 mbuf 256 1 385 396 mbuf_packet 256 781 243 956 audit_record 984 0 0 0 VMSPACE 416 10 44 841 SLEEPQUEUE 64 113 111 113 UPCALL 88 0 0 0 THREAD 824 103 9 103 PROC 1128 61 38 892 umtx pi 96 0 0 0 TURNSTILE 152 113 31 113 Files 120 73 82 4722 4096 4096 345 76 4049 2048 2048 65 11 302 1024 1024 60 152 2484 512 512 537 72 2490 256 256 601 74 4734 128 128 3535 90 10183 64 64 1791 113 27916 32 32 2096 328 3186 16 16 1666 350 31457 mt_zone 1024 217 7 217 DP fakepg 120 0 0 0 MAP ENTRY 112 200 196 27758 KMAP ENTRY 112 35 97 1448 MAP 248 7 23 7 VM OBJECT 208 585 99 12763 128 Bucket 1048 24 0 24 64 Bucket 536 34 1 34 32 Bucket 280 51 5 51 16 Bucket 152 73 2 73 UMA Hash 256 7 8 7 UMA RCntSlabs 128 516 6 516 UMA Slabs 128 625 13 1160 UMA Zones 216 89 13 89 UMA Kegs 216 89 13 89 db> show malloc Type InUse MemUse Requests msdosfs_mount 0 0K 0 msdosfs_fat 0 0K 0 msdosfs_fileno 0 0K 0 msdosfs_node 0 0K 0 DEVFS 27 1K 28 DEVFS_RULE 36 17K 36 DEVFS2 108 2K 108 DEVFS3 241 61K 242 DEVFS1 108 54K 108 USB 91 20K 106 USBdev 21 9K 21 atkbddev 2 1K 2 USBHC 0 0K 0 UART 0 0K 0 nexusdev 4 1K 4 msi 2 1K 2 twe_commands 0 0K 0 twa_commands 0 0K 0 firewire 0 0K 0 legacydrv 0 0K 0 io_apic 1 2K 1 entropy 1024 64K 1024 ppbusdev 3 1K 3 fw_xfer 0 0K 0 memdesc 1 4K 1 madt_table 0 0K 0 scsi_cd 0 0K 0 CAM ccb queue 0 0K 0 vm_pgdata 1 128K 1 acpipwr 0 0K 0 aaccam 0 0K 0 acpi_perf 0 0K 0 UMAHash 0 0K 0 ufs_mount 12 30K 12 ufs_quota 0 0K 0 ufs_dirhash 30 6K 30 pagedep 9 65K 16 inodedep 37 521K 49 newblk 1 1K 27 bmsafemap 6 1K 11 allocdirect 7 2K 23 indirdep 1 1K 5 allocindir 1 1K 3 freefrag 1 1K 2 freeblks 1 1K 4 freefile 3 1K 8 diradd 18 2K 28 mkdir 8 1K 12 dirrem 14 1K 25 newdirblk 0 0K 0 savedino 0 0K 12 audit_trigger 0 0K 0 audit_pipe 0 0K 0 audit_pipeent 0 0K 0 audit_pipe_preselect 0 0K 0 audit_evclass 150 5K 187 audit_bsm 0 0K 0 audit_cred 0 0K 0 audit_data 0 0K 0 audit_path 0 0K 0 audit_text 0 0K 0 rpcclnt 0 0K 0 agp 0 0K 0 nfss_srvsock 0 0K 0 nfss_srvdesc 0 0K 0 nfss_daemon 1 16K 1 nfsclient_lock 0 0K 0 nfsclient_nlminfo 0 0K 0 nfsclient_req 0 0K 0 nfsclient_bigfh 0 0K 0 nfsclient_diroff 0 0K 0 nfsclient_hash 0 0K 0 nfsclient_directio 0 0K 0 nfsclient_srvsock 0 0K 0 idmap 0 0K 0 nfs4_dev 0 0K 0 syncache 1 100K 1 tcplog 0 0K 0 aacbuf 0 0K 0 hostcache 1 36K 1 IpFw/IpAcct 1 1K 1 ipfw_tbl 0 0K 0 encap_export_host 0 0K 0 dummynet 0 0K 0 in_multi 4 1K 4 ip_moptions 0 0K 0 in_msource 0 0K 0 igmp 0 0K 0 routetbl 206 83K 465 pci_link 16 2K 16 tun 0 0K 0 SCSI SES 0 0K 0 sl 0 0K 0 ppp 0 0K 0 lo 1 1K 1 gif 0 0K 0 fw_com 0 0K 0 faith 0 0K 0 arpcom 3 1K 3 clone 6 24K 6 ifnet 7 13K 7 ifaddr 52 17K 52 ether_multi 17 1K 20 BPF 10 66K 11 subr_export_host 0 0K 0 SCSI sa 0 0K 0 mount 84 4K 138 vnodemarker 0 0K 20 vnodes 1 1K 1 vfs_hash 1 512K 1 export_host 0 0K 0 cl_savebuf 0 0K 0 vfscache 1 1024K 1 biobuf 38 76K 42 soname 5 1K 228 pcb 13 9K 15 CAM XPT 10 2K 25 mbuf_tag 12 1K 247 accf 0 0K 0 ptys 0 0K 0 ttys 403 70K 403 shm 1 16K 1 sem 4 8K 4 msg 4 30K 4 ioctlops 0 0K 1994 select 0 0K 0 iov 0 0K 1177 acpicmbat 0 0K 0 acpidev 63 4K 63 ciss_data 0 0K 0 CAM periph 2 1K 9 Unitno 7 1K 9 taskqueue 15 2K 15 stack 0 0K 0 CAM SIM 1 1K 1 scsi_da 0 0K 0 sbuf 0 0K 448 scsi_ch 0 0K 0 rman 161 20K 611 acpisem 12 2K 12 mfibuf 0 0K 0 kobj 227 908K 311 md_disk 0 0K 0 eventhandler 68 6K 68 devstat 16 33K 16 bus 961 75K 4819 bus-sc 66 83K 2400 md_sectors 0 0K 0 SWAP 0 0K 0 p1003.1b 1 1K 1 umtx 112 14K 112 sysctl 0 0K 143 sysctloid 2817 138K 2817 sysctltmp 0 0K 152 LED 0 0K 0 plimit 3 1K 254 uidinfo 4 3K 4 cred 11 3K 1266 pgrp 7 1K 7 session 7 1K 7 proc 2 16K 2 subproc 162 298K 993 kbdmux 6 9K 6 mtx_pool 1 8K 1 ipsbuf 0 0K 0 module 353 45K 353 iirbuf 0 0K 0 cache 0 0K 0 devbuf 314 1777K 321 temp 34 8K 3694 ip6opt 0 0K 0 ip6ndp 0 0K 0 CAM queue 3 1K 3 free 0 0K 0 lockf 2 1K 8 linker 96 132K 125 CAM dev queue 1 1K 1 KTRACE 100 13K 100 ast_driver 0 0K 0 afd_driver 0 0K 0 prison 0 0K 0 ithread 76 13K 76 acd_driver 0 0K 0 zombie 0 0K 0 proc-args 9 1K 327 kqueue 2 3K 2 kenv 71 11K 73 filedesc 64 33K 895 filedesc_to_leader 0 0K 0 sigio 1 1K 1 ar_driver 0 0K 10 ata_pci 0 0K 0 cdev 22 6K 22 sbp 0 0K 0 if_fwip 0 0K 0 ata_dma 2 1K 2 if_fwe 0 0K 0 ad_driver 2 1K 2 ata_generic 2 2K 2 acpitask 0 0K 1 isofs_mount 0 0K 0 isofs_node 0 0K 0 isadev 5 1K 5 acpica 1865 180K 58648 GEOM 144 25K 1163 fwmem 0 0K 0 pfs_vncache 0 0K 0 pfs_nodes 20 5K 20 ntfs_mount 0 0K 0 ntfs_ntnode 0 0K 0 ntfs_fnode 0 0K 0 ntfs_dir 0 0K 0 ntfs_vattr 0 0K 0 ntfsd_resdata 0 0K 0 ntfs_vrun 0 0K 0 ntfs_decomp 0 0K 0 ntfs_nthash 1 512K 1 db> show malloc Type InUse MemUse Requests msdosfs_mount 0 0K 0 msdosfs_fat 0 0K 0 msdosfs_fileno 0 0K 0 msdosfs_node 0 0K 0 DEVFS 27 1K 28 DEVFS_RULE 36 17K 36 DEVFS2 108 2K 108 DEVFS3 241 61K 242 DEVFS1 108 54K 108 USB 91 20K 106 USBdev 21 9K 21 atkbddev 2 1K 2 USBHC 0 0K 0 UART 0 0K 0 nexusdev 4 1K 4 msi 2 1K 2 twe_commands 0 0K 0 twa_commands 0 0K 0 firewire 0 0K 0 legacydrv 0 0K 0 io_apic 1 2K 1 entropy 1024 64K 1024 ppbusdev 3 1K 3 fw_xfer 0 0K 0 memdesc 1 4K 1 madt_table 0 0K 0 scsi_cd 0 0K 0 CAM ccb queue 0 0K 0 vm_pgdata 1 128K 1 acpipwr 0 0K 0 aaccam 0 0K 0 acpi_perf 0 0K 0 UMAHash 0 0K 0 ufs_mount 12 30K 12 ufs_quota 0 0K 0 ufs_dirhash 30 6K 30 pagedep 9 65K 16 inodedep 37 521K 49 newblk 1 1K 27 bmsafemap 6 1K 11 allocdirect 7 2K 23 indirdep 1 1K 5 allocindir 1 1K 3 freefrag 1 1K 2 freeblks 1 1K 4 freefile 3 1K 8 diradd 18 2K 28 mkdir 8 1K 12 dirrem 14 1K 25 newdirblk 0 0K 0 savedino 0 0K 12 audit_trigger 0 0K 0 audit_pipe 0 0K 0 audit_pipeent 0 0K 0 audit_pipe_preselect 0 0K 0 audit_evclass 150 5K 187 audit_bsm 0 0K 0 audit_cred 0 0K 0 audit_data 0 0K 0 audit_path 0 0K 0 audit_text 0 0K 0 rpcclnt 0 0K 0 agp 0 0K 0 nfss_srvsock 0 0K 0 nfss_srvdesc 0 0K 0 nfss_daemon 1 16K 1 nfsclient_lock 0 0K 0 nfsclient_nlminfo 0 0K 0 nfsclient_req 0 0K 0 nfsclient_bigfh 0 0K 0 nfsclient_diroff 0 0K 0 nfsclient_hash 0 0K 0 nfsclient_directio 0 0K 0 nfsclient_srvsock 0 0K 0 idmap 0 0K 0 nfs4_dev 0 0K 0 syncache 1 100K 1 tcplog 0 0K 0 aacbuf 0 0K 0 hostcache 1 36K 1 IpFw/IpAcct 1 1K 1 ipfw_tbl 0 0K 0 encap_export_host 0 0K 0 dummynet 0 0K 0 in_multi 4 1K 4 ip_moptions 0 0K 0 in_msource 0 0K 0 igmp 0 0K 0 routetbl 206 83K 465 pci_link 16 2K 16 tun 0 0K 0 SCSI SES 0 0K 0 sl 0 0K 0 ppp 0 0K 0 lo 1 1K 1 gif 0 0K 0 fw_com 0 0K 0 faith 0 0K 0 arpcom 3 1K 3 clone 6 24K 6 ifnet 7 13K 7 ifaddr 52 17K 52 ether_multi 17 1K 20 BPF 10 66K 11 subr_export_host 0 0K 0 SCSI sa 0 0K 0 mount 84 4K 138 vnodemarker 0 0K 20 vnodes 1 1K 1 vfs_hash 1 512K 1 export_host 0 0K 0 cl_savebuf 0 0K 0 vfscache 1 1024K 1 biobuf 38 76K 42 soname 5 1K 228 pcb 13 9K 15 CAM XPT 10 2K 25 mbuf_tag 12 1K 247 accf 0 0K 0 ptys 0 0K 0 ttys 403 70K 403 shm 1 16K 1 sem 4 8K 4 msg 4 30K 4 ioctlops 0 0K 1994 select 0 0K 0 iov 0 0K 1177 acpicmbat 0 0K 0 acpidev 63 4K 63 ciss_data 0 0K 0 CAM periph 2 1K 9 Unitno 7 1K 9 taskqueue 15 2K 15 stack 0 0K 0 CAM SIM 1 1K 1 scsi_da 0 0K 0 sbuf 0 0K 448 scsi_ch 0 0K 0 rman 161 20K 611 acpisem 12 2K 12 mfibuf 0 0K 0 kobj 227 908K 311 md_disk 0 0K 0 eventhandler 68 6K 68 devstat 16 33K 16 bus 961 75K 4819 bus-sc 66 83K 2400 md_sectors 0 0K 0 SWAP 0 0K 0 p1003.1b 1 1K 1 umtx 112 14K 112 sysctl 0 0K 143 sysctloid 2817 138K 2817 sysctltmp 0 0K 152 LED 0 0K 0 plimit 3 1K 254 uidinfo 4 3K 4 cred 11 3K 1266 pgrp 7 1K 7 session 7 1K 7 proc 2 16K 2 subproc 162 298K 993 kbdmux 6 9K 6 mtx_pool 1 8K 1 ipsbuf 0 0K 0 module 353 45K 353 iirbuf 0 0K 0 cache 0 0K 0 devbuf 314 1777K 321 temp 34 8K 3694 ip6opt 0 0K 0 ip6ndp 0 0K 0 CAM queue 3 1K 3 free 0 0K 0 lockf 2 1K 8 linker 96 132K 125 CAM dev queue 1 1K 1 KTRACE 100 13K 100 ast_driver 0 0K 0 afd_driver 0 0K 0 prison 0 0K 0 ithread 76 13K 76 acd_driver 0 0K 0 zombie 0 0K 0 proc-args 9 1K 327 kqueue 2 3K 2 kenv 71 11K 73 filedesc 64 33K 895 filedesc_to_leader 0 0K 0 sigio 1 1K 1 ar_driver 0 0K 10 ata_pci 0 0K 0 cdev 22 6K 22 sbp 0 0K 0 if_fwip 0 0K 0 ata_dma 2 1K 2 if_fwe 0 0K 0 ad_driver 2 1K 2 ata_generic 2 2K 2 acpitask 0 0K 1 isofs_mount 0 0K 0 isofs_node 0 0K 0 isadev 5 1K 5 acpica 1865 180K 58648 GEOM 144 25K 1163 fwmem 0 0K 0 pfs_vncache 0 0K 0 pfs_nodes 20 5K 20 ntfs_mount 0 0K 0 ntfs_ntnode 0 0K 0 ntfs_fnode 0 0K 0 ntfs_dir 0 0K 0 ntfs_vattr 0 0K 0 ntfsd_resdata 0 0K 0 ntfs_vrun 0 0K 0 ntfs_decomp 0 0K 0 ntfs_nthash 1 512K 1 db> cont [...] lock order reversal: 1st 0xffffffff8096eb88 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff8096f8a8 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:385 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x539 _mtx_lock_flags() at _mtx_lock_flags+0x1f udp_input() at udp_input+0x1f7 ip_input() at ip_input+0xa7 dummynet_send() at dummynet_send+0xde dummynet_io() at dummynet_io+0x587 ipfw_check_in() at ipfw_check_in+0x241 pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- KDB: enter: witness_checkorder [thread pid 24 tid 100023 ] Stopped at kdb_enter+0x31: popq %rbp db> cont --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="second-lor.txt" lock order reversal: 1st 0xffffffff8096eb88 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff8096f8a8 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:385 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x539 _mtx_lock_flags() at _mtx_lock_flags+0x1f udp_input() at udp_input+0x1f7 ip_input() at ip_input+0xa7 dummynet_send() at dummynet_send+0xde dummynet_io() at dummynet_io+0x587 ipfw_check_in() at ipfw_check_in+0x241 pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- KDB: enter: witness_checkorder [thread pid 24 tid 100023 ] Stopped at kdb_enter+0x31: popq %rbp db> show pcpu cpuid = 1 curthread = 0xffffff00011bf000: pid 24 "em1 taskq" curpcb = 0xffffffffa057ad40 fpcurthread = none idlethread = 0xffffff000107f680: pid 11 "idle: cpu1" spin locks held: db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xffffff0001eb3000: pid 44042 "sh" curpcb = 0xffffffffa2ad9d40 fpcurthread = none idlethread = 0xffffff000107f340: pid 12 "idle: cpu0" spin locks held: cpuid = 1 curthread = 0xffffff00011bf000: pid 24 "em1 taskq" curpcb = 0xffffffffa057ad40 fpcurthread = none idlethread = 0xffffff000107f680: pid 11 "idle: cpu1" spin locks held: db> trace Tracing pid 24 tid 100023 td 0xffffff00011bf000 kdb_enter() at kdb_enter+0x31 witness_checkorder() at witness_checkorder+0x48e _mtx_lock_flags() at _mtx_lock_flags+0x1f udp_input() at udp_input+0x1f7 ip_input() at ip_input+0xa7 dummynet_send() at dummynet_send+0xde dummynet_io() at dummynet_io+0x587 ipfw_check_in() at ipfw_check_in+0x241 pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- db> alltrace Tracing command sh pid 44042 tid 100110 td 0xffffff0001eb3000 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x32 trap() at trap+0x2fd nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x80052135a, rsp = 0x7fffffffcb10, rbp = 0x51df48 --- Tracing command sh pid 44022 tid 100124 td 0xffffff001106b9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa pipe_read() at pipe_read+0x264 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800993acc, rsp = 0x7fffffffcd98, r bp = 0x800b3ee0e --- Tracing command sbcl pid 42648 tid 100119 td 0xffffff001106f000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec bwait() at bwait+0x55 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x2f7 vn_read() at vn_read+0x1d3 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800951acc, rsp = 0x7fffffffecd8, r bp = 0x7fffffffed40 --- Tracing command python pid 42488 tid 100090 td 0xffffff0001820000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec acquire() at acquire+0x5d _lockmgr() at _lockmgr+0x24f ffs_lock() at ffs_lock+0x71 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 _vn_lock() at _vn_lock+0x83 vget() at vget+0xbd cache_lookup() at cache_lookup+0x1d0 vfs_cache_lookup() at vfs_cache_lookup+0xb0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x41 lookup() at lookup+0x43d namei() at namei+0x304 kern_stat() at kern_stat+0x56 stat() at stat+0x22 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (188, FreeBSD ELF64, stat), rip = 0x800b1014c, rsp = 0x7fffffffb138, rbp = 0x800e15cb0 --- Tracing command python pid 42307 tid 100117 td 0xffffff001106f680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec bwait() at bwait+0x55 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_blkatoff() at ffs_blkatoff+0x56 ufs_lookup() at ufs_lookup+0x553 vfs_cache_lookup() at vfs_cache_lookup+0xe5 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x41 lookup() at lookup+0x43d namei() at namei+0x304 kern_stat() at kern_stat+0x56 stat() at stat+0x22 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (188, FreeBSD ELF64, stat), rip = 0x800b1014c, rsp = 0x7fffffffbff8, rbp = 0 --- Tracing command detachtty pid 42114 tid 100114 td 0xffffff0011128340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d poll() at poll+0x583 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x8007c79dc, rsp = 0x7fffffffeb38, rbp = 0x7fffffffed10 --- Tracing command cron pid 41177 tid 100086 td 0xffffff0001821000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba kern_nanosleep() at kern_nanosleep+0x10a nanosleep() at nanosleep+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80090730c, rsp = 0x7fffffff ec28, rbp = 0x5 --- Tracing command httpd pid 41081 tid 100058 td 0xffffff0001408340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe7b8, rbp = 0x7fffffffea48 --- Tracing command httpd pid 41067 tid 100055 td 0xffffff000129b680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe808 --- Tracing command httpd pid 40958 tid 100104 td 0xffffff0001452000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe808 --- Tracing command httpd pid 40871 tid 100103 td 0xffffff0001452340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9f8 , rbp = 0x7fffffffea68 --- Tracing command httpd pid 40776 tid 100065 td 0xffffff00013fd340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9f8 , rbp = 0x7fffffffea68 --- Tracing command httpd pid 40720 tid 100063 td 0xffffff00013fd9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe808 --- Tracing command httpd pid 40471 tid 100095 td 0xffffff00017c69c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe808 --- Tracing command httpd pid 40372 tid 100054 td 0xffffff000129b9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe7b8, rbp = 0x7fffffffea48 --- Tracing command httpd pid 40301 tid 100052 td 0xffffff00014089c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9f8 , rbp = 0x7fffffffea68 --- Tracing command sshd pid 40142 tid 100064 td 0xffffff00013fd680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x8016d7a4c, rsp = 0x7fffffffe618 , rbp = 0x3 --- Tracing command httpd pid 39930 tid 100061 td 0xffffff00014539c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x800fb19dc, rsp = 0x7fffffffe798, rbp = 0x7fffffffea28 --- Tracing command httpd pid 39568 tid 100066 td 0xffffff00013fd000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800ffea4c, rsp = 0x7fffffffeab8 , rbp = 0 --- Tracing command httpd pid 39491 tid 100068 td 0xffffff0001404680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9d8 , rbp = 0x7fffffffea48 --- Tracing command httpd pid 39418 tid 100073 td 0xffffff000146b000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9d8 , rbp = 0x7fffffffea48 --- Tracing command httpd pid 39362 tid 100059 td 0xffffff0001454000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9d8 , rbp = 0x7fffffffea48 --- Tracing command httpd pid 39263 tid 100093 td 0xffffff00017c7340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9d8 , rbp = 0x7fffffffea48 --- Tracing command httpd pid 39182 tid 100051 td 0xffffff0001353340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_accept() at kern_accept+0x1cf accept() at accept+0x61 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800fa454c, rsp = 0x7fffffffe9d8 , rbp = 0x7fffffffea48 --- Tracing command httpd pid 38789 tid 100062 td 0xffffff0001453680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800ffea4c, rsp = 0x7fffffffeab8 , rbp = 0 --- Tracing command bgpd pid 38165 tid 100076 td 0xffffff000147b340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006e39dc, rsp = 0x7fffffffec18, rbp = 0x47e4a337 --- Tracing command bgpd pid 38092 tid 100067 td 0xffffff00014049c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d poll() at poll+0x583 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006e39dc, rsp = 0x7fffffffec38, rbp = 0 --- Tracing command bgpd pid 38018 tid 100069 td 0xffffff0001404340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006e39dc, rsp = 0x7fffffffeca8, rbp = 0x9515 --- Tracing command postgres pid 37711 tid 100053 td 0xffffff0001353000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b poll() at poll+0x1d2 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (209, FreeBSD ELF64, poll), rip = 0x8014469dc, rsp = 0x7fffffffcff8, rbp = 0x40 --- Tracing command postgres pid 37633 tid 100078 td 0xffffff000147a9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x801493a4c, rsp = 0x7fffffffd3e8 , rbp = 0 --- Tracing command postgres pid 37595 tid 100088 td 0xffffff0001820680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x801493a4c, rsp = 0x7fffffffd348 , rbp = 0 --- Tracing command postgres pid 37564 tid 100075 td 0xffffff000147b680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x801493a4c, rsp = 0x7fffffffd318 , rbp = 0 --- Tracing command postgres pid 37543 tid 100070 td 0xffffff0001404000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x12b kern_select() at kern_select+0x833 select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x801493a4c, rsp = 0x7fffffffd9a8 , rbp = 0x6 --- Tracing command unlinkd pid 37266 tid 100083 td 0xffffff0001454680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa pipe_read() at pipe_read+0x264 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800704acc, rsp = 0x7fffffffe808, r bp = 0x7fffffffecd8 --- Tracing command squid pid 36740 tid 100060 td 0xffffff0001408000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ast() at ast+0x159 Xfast_syscall() at Xfast_syscall+0xe0 --- syscall (72, FreeBSD ELF64, ovadvise), rip = 0x8009d7aac, rsp = 0x7fffffffe9 28, rbp = 0xbd0 --- Tracing command squid pid 36671 tid 100094 td 0xffffff00017c7000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800967abc, rsp = 0x7fffffffeb18, rbp = 0x7fffffffecc8 --- Tracing command dhcpd pid 36225 tid 100081 td 0xffffff000147a000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800772a4c, rsp = 0x7fffffffe9d8 , rbp = 0 --- Tracing command ntpd pid 34475 tid 100096 td 0xffffff00017c6680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba kern_kevent() at kern_kevent+0x36a kevent() at kevent+0x85 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800bd531c, rsp = 0x7fffffffcc0 8, rbp = 0xf --- Tracing command named pid 29710 tid 100102 td 0xffffff0001452680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c03a4c, rsp = 0x7fffff5fbcc8 , rbp = 0x26 --- Tracing command named pid 29710 tid 100101 td 0xffffff00014529c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba do_cv_wait() at do_cv_wait+0x312 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffff7fc dc8, rbp = 0x7fffff7fce30 --- Tracing command named pid 29710 tid 100100 td 0xffffff0001453000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa do_cv_wait() at do_cv_wait+0x4c2 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffff9fd eb8, rbp = 0 --- Tracing command named pid 29710 tid 100099 td 0xffffff0001453340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa do_cv_wait() at do_cv_wait+0x4c2 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x51 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b7d94c, rsp = 0x7fffffbfe eb8, rbp = 0 --- Tracing command named pid 29710 tid 100087 td 0xffffff00018209c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_sigtimedwait() at kern_sigtimedwait+0x4ea sigwait() at sigwait+0x63 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x800b7dc6c, rsp = 0x7fffffffec 48, rbp = 0x800e01120 --- Tracing command syslogd pid 26625 tid 100074 td 0xffffff000147b9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80081aa4c, rsp = 0x7fffffffdda8 , rbp = 0x800a1c0f0 --- Tracing command accounting pid 24352 tid 100085 td 0xffffff0001821340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 acct_thread() at acct_thread+0x1c3 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa2a5cd30, rbp = 0 --- Tracing command devd pid 22944 tid 100082 td 0xffffff00014549c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x11d kern_select() at kern_select+0x85f select() at select+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x43796c, rsp = 0x7fffffffe928, r bp = 0x7fffffffed50 --- Tracing command pflogd pid 14667 tid 100080 td 0xffffff000147a340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x2ba bpfread() at bpfread+0xde devfs_read_f() at devfs_read_f+0x67 dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800940acc, rsp = 0x7fffffffed08, r bp = 0x1 --- Tracing command pflogd pid 14530 tid 100056 td 0xffffff000129b340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa soreceive_generic() at soreceive_generic+0xd1a dofileread() at dofileread+0x8d kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800940acc, rsp = 0x7fffffffe938, r bp = 0x4 --- Tracing command pfpurge pid 14486 tid 100071 td 0xffffff000146b680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 pf_purge_thread() at pf_purge_thread+0x60 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa29efd30, rbp = 0 --- Tracing command sh pid 51 tid 100050 td 0xffffff0001353680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800923abc, rsp = 0x7fffffffe6d8, rbp = 0x33 --- Tracing command schedcpu pid 50 tid 100049 td 0xffffff00013539c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 schedcpu_thread() at schedcpu_thread+0x209 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa2981d30, rbp = 0 --- Tracing command softdepflush pid 49 tid 100048 td 0xffffff0001355000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 softdep_flush() at softdep_flush+0x2da fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0679d30, rbp = 0 --- Tracing command syncer pid 48 tid 100047 td 0xffffff0001355340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec sched_sync() at sched_sync+0x5da fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0674d30, rbp = 0 --- Tracing command vnlru pid 47 tid 100046 td 0xffffff0001355680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vnlru_proc() at vnlru_proc+0x692 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa066fd30, rbp = 0 --- Tracing command bufdaemon pid 46 tid 100045 td 0xffffff00013559c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 buf_daemon() at buf_daemon+0x225 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa066ad30, rbp = 0 --- Tracing command pagezero pid 45 tid 100044 td 0xffffff00012479c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vm_pagezero() at vm_pagezero+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0665d30, rbp = 0 --- Tracing command vmdaemon pid 44 tid 100043 td 0xffffff0001298000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0660d30, rbp = 0 --- Tracing command pagedaemon pid 43 tid 100042 td 0xffffff0001298340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 vm_pageout() at vm_pageout+0xa62 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa065bd30, rbp = 0 --- Tracing command dummynet pid 42 tid 100041 td 0xffffff0001298680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 msleep_spin() at msleep_spin+0x18f taskqueue_thread_loop() at taskqueue_thread_loop+0x45 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0656d30, rbp = 0 --- Tracing command irq1: atkbd0 pid 41 tid 100040 td 0xffffff00012989c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0631d30, rbp = 0 --- Tracing command irq7: ppbus0 ppc0 pid 40 tid 100039 td 0xffffff0001299000 fork_trampoline() at fork_trampoline Tracing command swi0: sio pid 39 tid 100038 td 0xffffff0001299340 fork_trampoline() at fork_trampoline Tracing command fdc0 pid 38 tid 100037 td 0xffffff0001299680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 fdc_thread() at fdc_thread+0x7b5 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0622d30, rbp = 0 --- Tracing command irq15: ata1 pid 37 tid 100036 td 0xffffff00012999c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0613d30, rbp = 0 --- Tracing command irq14: ata0 pid 36 tid 100035 td 0xffffff000129b000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05fbd30, rbp = 0 --- Tracing command usb4 pid 35 tid 100034 td 0xffffff00011c0680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05e3d30, rbp = 0 --- Tracing command usb3 pid 34 tid 100033 td 0xffffff00011c09c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05ccd30, rbp = 0 --- Tracing command irq16: uhci3 pid 33 tid 100032 td 0xffffff0001246000 fork_trampoline() at fork_trampoline Tracing command usb2 pid 32 tid 100031 td 0xffffff0001246340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05c1d30, rbp = 0 --- Tracing command usb1 pid 31 tid 100030 td 0xffffff0001246680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05bbd30, rbp = 0 --- Tracing command irq19: uhci1 pid 30 tid 100029 td 0xffffff00012469c0 fork_trampoline() at fork_trampoline Tracing command usbtask-dr pid 29 tid 100028 td 0xffffff0001247000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec usb_task_thread() at usb_task_thread+0x99 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05b0d30, rbp = 0 --- Tracing command usbtask-hc pid 28 tid 100027 td 0xffffff0001247340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec usb_task_thread() at usb_task_thread+0x99 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05abd30, rbp = 0 --- Tracing command usb0 pid 27 tid 100026 td 0xffffff0001247680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 usb_event_thread() at usb_event_thread+0xb0 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa05a6d30, rbp = 0 --- Tracing command irq23: uhci0 ehci0 pid 26 tid 100025 td 0xffffff00011a6680 fork_trampoline() at fork_trampoline Tracing command irq18: bge0 uhci2 pid 25 tid 100024 td 0xffffff00011a69c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa059bd30, rbp = 0 --- Tracing command em1 taskq pid 24 tid 100023 td 0xffffff00011bf000 kdb_enter() at kdb_enter+0x31 witness_checkorder() at witness_checkorder+0x48e _mtx_lock_flags() at _mtx_lock_flags+0x1f udp_input() at udp_input+0x1f7 ip_input() at ip_input+0xa7 dummynet_send() at dummynet_send+0xde dummynet_io() at dummynet_io+0x587 ipfw_check_in() at ipfw_check_in+0x241 pfil_run_hooks() at pfil_run_hooks+0xac ip_input() at ip_input+0x292 ether_demux() at ether_demux+0x1ac ether_input() at ether_input+0x1bf em_handle_rxtx() at em_handle_rxtx+0x1d2 taskqueue_run() at taskqueue_run+0x95 taskqueue_thread_loop() at taskqueue_thread_loop+0x53 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa057ad30, rbp = 0 --- Tracing command em0 taskq pid 23 tid 100022 td 0xffffff00011bf340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 msleep_spin() at msleep_spin+0x18f taskqueue_thread_loop() at taskqueue_thread_loop+0x45 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0555d30, rbp = 0 --- Tracing command irq9: acpi0 pid 22 tid 100021 td 0xffffff00011bf680 fork_trampoline() at fork_trampoline Tracing command kqueue taskq pid 21 tid 100020 td 0xffffff00011bf9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa052bd30, rbp = 0 --- Tracing command swi6: task queue pid 20 tid 100019 td 0xffffff00011c0000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0526d30, rbp = 0 --- Tracing command swi6: Giant taskq pid 19 tid 100018 td 0xffffff00011c0340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0521d30, rbp = 0 --- Tracing command thread taskq pid 9 tid 100017 td 0xffffff000108c9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa051cd30, rbp = 0 --- Tracing command swi5: + pid 18 tid 100016 td 0xffffff00011a5000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0517d30, rbp = 0 --- Tracing command swi2: cambio pid 17 tid 100015 td 0xffffff00011a5340 fork_trampoline() at fork_trampoline Tracing command xpt_thrd pid 8 tid 100014 td 0xffffff00011a5680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec xpt_scanner_thread() at xpt_scanner_thread+0x38 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa050dd30, rbp = 0 --- Tracing command acpi_task_2 pid 7 tid 100013 td 0xffffff00011a59c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0508d30, rbp = 0 --- Tracing command acpi_task_1 pid 6 tid 100012 td 0xffffff00011a6000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa0503d30, rbp = 0 --- Tracing command acpi_task_0 pid 5 tid 100011 td 0xffffff00011a6340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _sleep() at _sleep+0x1ec taskqueue_thread_loop() at taskqueue_thread_loop+0x71 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04fed30, rbp = 0 --- Tracing command yarrow pid 16 tid 100010 td 0xffffff0001080340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 random_kthread() at random_kthread+0x1a4 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04f5d30, rbp = 0 --- Tracing command g_down pid 4 tid 100009 td 0xffffff0001080680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_io_schedule_down() at g_io_schedule_down+0x201 g_down_procbody() at g_down_procbody+0x55 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04f0d30, rbp = 0 --- Tracing command g_up pid 3 tid 100008 td 0xffffff00010809c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_io_schedule_up() at g_io_schedule_up+0x119 g_up_procbody() at g_up_procbody+0x55 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04ebd30, rbp = 0 --- Tracing command g_event pid 2 tid 100007 td 0xffffff000108c000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x1d4 g_event_procbody() at g_event_procbody+0xa9 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04e6d30, rbp = 0 --- Tracing command swi3: vm pid 15 tid 100006 td 0xffffff000108c340 fork_trampoline() at fork_trampoline Tracing command swi4: clock sio pid 14 tid 100005 td 0xffffff000108c680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04dcd30, rbp = 0 --- Tracing command swi1: net pid 13 tid 100004 td 0xffffff000107f000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 ithread_loop() at ithread_loop+0x2d1 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04d7d30, rbp = 0 --- Tracing command idle: cpu0 pid 12 tid 100003 td 0xffffff000107f340 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sched_idletd() at sched_idletd+0x3c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04d1d30, rbp = 0 --- Tracing command idle: cpu1 pid 11 tid 100002 td 0xffffff000107f680 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sched_idletd() at sched_idletd+0x3c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04ccd30, rbp = 0 --- Tracing command init pid 1 tid 100001 td 0xffffff000107f9c0 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_catch_signals() at sleepq_catch_signals+0x1c5 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x2aa kern_wait() at kern_wait+0x3c0 wait4() at wait4+0x33 syscall() at syscall+0x1b5 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40b61c, rsp = 0x7fffffffe848, rbp = 0x33 --- Tracing command audit pid 10 tid 100000 td 0xffffff0001080000 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x31 _cv_wait() at _cv_wait+0x115 audit_worker() at audit_worker+0x47f fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa04c2d30, rbp = 0 --- Tracing command swapper pid 0 tid 0 td 0xffffffff808def70 sched_switch() at sched_switch+0x131 mi_switch() at mi_switch+0x186 scheduler() at scheduler+0x39e mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> show alllocks Process 14530 (pflogd) thread 0xffffff000129b340 (100056) exclusive sx so_rcv_sx r = 0 (0xffffff000140f3b8) locked @ /usr/src/sys/kern/uip c_sockbuf.c:148 Process 24 (em1 taskq) thread 0xffffff00011bf000 (100023) shared rw PFil hook read/write mutex r = 0 (0xffffffff8096eb88) locked @ /usr/sr c/sys/net/pfil.c:73 db> show witness Sleep locks: 0 so_rcv_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 7 so_rcv -- last acquired @ /usr/src/sys/kern/uipc_socket.c:2475 13 sellck -- last acquired @ /usr/src/sys/kern/sys_generic.c:1127 8 radix node head -- last acquired @ /usr/src/sys/net/route.c:147 11 rtentry -- last acquired @ /usr/src/sys/netinet/ip_output.c:594 12 ifaddr -- last acquired @ /usr/src/sys/net/route.c:287 12 rts_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 12 UMA zone -- last acquired @ /usr/src/sys/vm/uma_core.c:1874 12 vm page queue free mutex -- last acquired @ /usr/src/sys/vm/vm_page.c:1030 12 UMA zone -- (already displayed) 11 UMA boot pages -- last acquired @ /usr/src/sys/vm/uma_core.c:916 12 vm page queue free mutex -- (already displayed) 9 ifnet -- last acquired @ /usr/src/sys/net/if.c:1473 11 eventhandler -- last acquired @ /usr/src/sys/kern/subr_eventhandler.c:212 12 eventhandler list -- last acquired @ /usr/src/sys/kern/kern_exit.c:233 10 if_addr_mtx -- last acquired @ /usr/src/sys/net/if.c:828 10 pf task mtx -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/ne t/pf.c:6729 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 UMA boot pages -- (already displayed) 11 arc4_mtx -- last acquired @ /usr/src/sys/libkern/arc4random.c:137 11 bpf interface lock -- last acquired @ /usr/src/sys/net/bpf.c:1359 12 bpf cdev lock -- last acquired @ /usr/src/sys/net/bpf.c:1363 13 sellck -- (already displayed) 11 eventhandler -- (already displayed) 11 rtentry -- (already displayed) 12 eventhandler list -- (already displayed) 8 process lock -- last acquired @ /usr/src/sys/amd64/amd64/trap.c:622 9 session -- last acquired @ /usr/src/sys/kern/kern_fork.c:582 10 uidinfo hash -- last acquired @ /usr/src/sys/kern/kern_resource.c:1213 11 uidinfo struct -- last acquired @ order list:0 11 sleep mtxpool -- last acquired @ /usr/src/sys/kern/kern_descrip.c:2139 12 kqueue -- last acquired @ /usr/src/sys/kern/kern_event.c:1021 13 struct mount mtx -- last acquired @ /usr/src/sys/kern/vfs_mount.c:440 14 vnode interlock -- last acquired @ /usr/src/sys/kern/vfs_subr.c:2186 15 cdev -- last acquired @ /usr/src/sys/kern/kern_conf.c:69 15 vnode_free_list -- last acquired @ /usr/src/sys/kern/vfs_subr.c:3012 15 Syncer mtx -- last acquired @ /usr/src/sys/kern/vfs_subr.c:1915 10 tty -- last acquired @ /usr/src/sys/kern/kern_event.c:1664 9 sigacts -- last acquired @ /usr/src/sys/kern/subr_sleepqueue.c:392 9 ktrace -- last acquired @ /usr/src/sys/kern/kern_fork.c:600 11 sleep mtxpool -- (already displayed) 11 sleep mtxpool -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 12 kqueue -- (already displayed) 11 UMA boot pages -- (already displayed) 8 process lock -- (already displayed) 2 unp_mtx -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:557 3 accept -- last acquired @ /usr/src/sys/kern/uipc_socket.c:685 6 so_snd -- last acquired @ /usr/src/sys/kern/uipc_socket.c:2474 7 so_rcv -- (already displayed) 11 sleep mtxpool -- (already displayed) 8 radix node head -- (already displayed) 11 rtentry -- (already displayed) 7 tcp_hc_entry -- last acquired @ /usr/src/sys/netinet/tcp_hostcache.c:291 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 13 sellck -- (already displayed) 12 kqueue -- (already displayed) 12 UMA zone -- (already displayed) 9 vm page queue mutex -- last acquired @ /usr/src/sys/vm/vm_fault.c:887 14 vnode interlock -- (already displayed) 10 pmap -- last acquired @ /usr/src/sys/amd64/amd64/pmap.c:3076 12 vm page queue free mutex -- (already displayed) 12 vm page queue free mutex -- (already displayed) 7 so_rcv -- (already displayed) 7 so_rcv -- (already displayed) 6 so_snd -- (already displayed) 3 filedesc structure -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1025 14 vnode interlock -- (already displayed) 8 process lock -- (already displayed) 11 sleep mtxpool -- (already displayed) 5 Name Cache -- last acquired @ /usr/src/sys/kern/vfs_cache.c:327 14 vnode interlock -- (already displayed) 12 UMA zone -- (already displayed) 11 UMA boot pages -- (already displayed) 4 fdesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1472 15 cdev -- (already displayed) 4 Giant -- last acquired @ /usr/src/sys/kern/kern_timeout.c:241 5 pipe mutex -- last acquired @ /usr/src/sys/kern/sys_pipe.c:572 6 sigio lock -- last acquired @ /usr/src/sys/kern/kern_descrip.c:782 7 process group -- last acquired @ /usr/src/sys/kern/kern_fork.c:572 8 process lock -- (already displayed) 9 session -- (already displayed) 13 sellck -- (already displayed) 12 UMA zone -- (already displayed) 7 system map -- last acquired @ /usr/src/sys/vm/vm_map.c:3111 9 vm page queue mutex -- (already displayed) 8 kmem object -- last acquired @ /usr/src/sys/vm/vm_kern.c:410 12 vm page queue free mutex -- (already displayed) 9 vm page queue mutex -- (already displayed) 8 kernel object -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3641 12 vm page queue free mutex -- (already displayed) 9 vm page queue mutex -- (already displayed) 12 vm page queue free mutex -- (already displayed) 10 pmap -- (already displayed) 8 KMAP ENTRY -- last acquired @ /usr/src/sys/vm/uma_core.c:414 12 UMA zone -- (already displayed) 8 standard object -- last acquired @ /usr/src/sys/vm/vm_object.c:441 12 vm page queue free mutex -- (already displayed) 14 vnode interlock -- (already displayed) 9 vm page queue mutex -- (already displayed) 9 vm object_list -- last acquired @ /usr/src/sys/vm/vm_object.c:225 12 UMA zone -- (already displayed) 9 swap_pager swhash -- last acquired @ /usr/src/sys/vm/swap_pager.c:1888 5 UMA lock -- last acquired @ /usr/src/sys/vm/uma_core.c:1492 12 UMA zone -- (already displayed) 8 KMAP ENTRY -- (already displayed) 11 UMA boot pages -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 5 kobj -- last acquired @ /usr/src/sys/kern/subr_kobj.c:307 6 kernel environment -- last acquired @ /usr/src/sys/kern/kern_environment.c: 301 8 kernel object -- (already displayed) 9 vm object_list -- (already displayed) 8 KMAP ENTRY -- (already displayed) 10 uidinfo hash -- (already displayed) 8 process lock -- (already displayed) 11 sleep mtxpool -- (already displayed) 5 evclass_mtx -- last acquired @ /usr/src/sys/security/audit/audit_bsm_klib.c :112 5 TID lock -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 8 standard object -- (already displayed) 5 intr event -- last acquired @ /usr/src/sys/kern/kern_intr.c:454 15 cdev -- (already displayed) 5 GEOM orphanage -- last acquired @ /usr/src/sys/geom/geom_event.c:201 5 ttylist -- last acquired @ /usr/src/sys/kern/tty.c:2901 10 tty -- (already displayed) 5 intr config -- last acquired @ /usr/src/sys/kern/subr_autoconf.c:73 5 taskqueue list -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:125 5 XPT lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:2668 6 XPT topology lock -- last acquired @ /usr/src/sys/cam/cam_xpt.c:2673 6 kernel environment -- (already displayed) 7 taskqueue -- last acquired @ /usr/src/sys/kern/subr_taskqueue.c:73 5 rman head -- last acquired @ /usr/src/sys/kern/subr_rman.c:152 5 rman -- last acquired @ /usr/src/sys/kern/subr_rman.c:539 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 5 devd -- last acquired @ /usr/src/sys/kern/subr_bus.c:489 13 sellck -- (already displayed) 13 sellck -- (already displayed) 5 ACPI semaphore -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdSynch.c:30 3 5 acpi subsystem HW lock -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdSy nch.c:377 5 acpi subsystem GPE lock -- last acquired @ /usr/src/sys/dev/acpica/Osd/OsdS ynch.c:377 7 taskqueue -- (already displayed) 5 msi -- last acquired @ /usr/src/sys/amd64/amd64/msi.c:389 9 ifnet -- (already displayed) 5 bpf global lock -- last acquired @ /usr/src/sys/net/bpf.c:396 11 bpf interface lock -- (already displayed) 5 bounce pages lock -- last acquired @ /usr/src/sys/amd64/amd64/busdma_machde p.c:1073 10 pmap -- (already displayed) 5 unit# allocation -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 15 vnode_free_list -- (already displayed) 5 pfs_node -- last acquired @ /usr/src/sys/fs/pseudofs/pseudofs_internal.h:10 3 5 pfs_fileno -- last acquired @ /usr/src/sys/kern/subr_unit.c:623 6 random reseed -- last acquired @ /usr/src/sys/dev/random/yarrow.c:191 11 arc4_mtx -- (already displayed) 5 nfsd_mtx -- last acquired @ /usr/src/sys/nfsserver/nfs_srvsock.c:796 6 so_snd -- (already displayed) 5 if_clone lock -- last acquired @ /usr/src/sys/net/if_clone.c:164 5 if_cloners lock -- last acquired @ /usr/src/sys/net/if_clone.c:252 5 domain list -- last acquired @ /usr/src/sys/kern/uipc_domain.c:228 6 pfil_head_list lock -- last acquired @ /usr/src/sys/net/pfil.c:159 5 PFil hook read/write mutex -- last acquired @ /usr/src/sys/net/pfil.c:73 6 pfil_head_list lock -- (already displayed) 10 pf task mtx -- (already displayed) 6 IPFW static rules -- last acquired @ /usr/src/sys/netinet/ip_fw2.c:2647 12 UMA zone -- (already displayed) 8 radix node head -- (already displayed) 7 if send queue -- last acquired @ /usr/src/sys/dev/em/if_em.c:949 6 network driver -- last acquired @ /usr/src/sys/dev/bge/if_bge.c:3014 10 if_addr_mtx -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 7 taskqueue -- (already displayed) 7 if send queue -- (already displayed) 6 ip_inq -- last acquired @ /usr/src/sys/net/netisr.c:140 11 rtentry -- (already displayed) 6 EM TX Lock -- last acquired @ /usr/src/sys/dev/em/if_em.c:980 7 if send queue -- (already displayed) 11 bpf interface lock -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 6 dummynet -- last acquired @ /usr/src/sys/netinet/ip_dummynet.c:739 12 UMA zone -- (already displayed) 7 system map -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 eventhandler -- (already displayed) 5 isn_mtx -- last acquired @ /usr/src/sys/netinet/tcp_subr.c:1426 6 random reseed -- (already displayed) 11 arc4_mtx -- (already displayed) 8 radix node head -- (already displayed) 6 IPFW static rules -- (already displayed) 5 lo_mtx -- last acquired @ /usr/src/sys/net/if_loop.c:161 5 ATA queue lock -- last acquired @ /usr/src/sys/dev/ata/ata-queue.c:177 6 ATA state lock -- last acquired @ /usr/src/sys/dev/ata/ata-queue.c:194 5 devstat -- last acquired @ /usr/src/sys/kern/subr_devstat.c:83 6 XPT topology lock -- (already displayed) 5 NFS iod lock -- last acquired @ /usr/src/sys/nfsclient/nfs_nfsiod.c:196 6 mountlist -- last acquired @ /usr/src/sys/ufs/ffs/ffs_softdep.c:760 13 struct mount mtx -- (already displayed) 13 struct mount mtx -- (already displayed) 5 mntid -- last acquired @ /usr/src/sys/kern/vfs_subr.c:460 6 mountlist -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:1468 14 vnode interlock -- (already displayed) 5 bio queue -- last acquired @ /usr/src/sys/geom/geom_io.c:68 5 bdone lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:3800 5 needsbuffer lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:321 5 FFS Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1149 11 arc4_mtx -- (already displayed) 5 Name Cache -- (already displayed) 5 knlist lock for lockless objects -- last acquired @ /usr/src/sys/kern/kern_ event.c:1664 5 vfs hash -- last acquired @ /usr/src/sys/kern/vfs_hash.c:71 14 vnode interlock -- (already displayed) 5 devfs interlock -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:194 14 vnode interlock -- (already displayed) 5 dirhash list -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:349 6 dirhash -- last acquired @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:368 6 dirhash -- (already displayed) 5 pbuf mutex -- last acquired @ /usr/src/sys/vm/vm_pager.c:413 9 vm page queue mutex -- (already displayed) 7 process group -- (already displayed) 10 tty -- (already displayed) 9 session -- (already displayed) 5 Softdep Lock -- last acquired @ /usr/src/sys/ufs/ffs/ffs_softdep.c:4892 7 system map -- (already displayed) 12 UMA zone -- (already displayed) 14 vnode interlock -- (already displayed) 6 buffer daemon lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:429 10 pf task mtx -- (already displayed) 6 buffer daemon lock -- (already displayed) 6 sigio lock -- (already displayed) 6 so_snd -- (already displayed) 5 pipe mutex -- (already displayed) 12 bpf cdev lock -- (already displayed) 12 kqueue -- (already displayed) 7 system map -- (already displayed) 12 UMA zone -- (already displayed) 7 so_rcv -- (already displayed) 4 protect sysfilt_ops -- last acquired @ /usr/src/sys/kern/kern_event.c:774 12 UMA zone -- (already displayed) 3 user map -- last acquired @ /usr/src/sys/vm/vm_map.c:3111 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 9 vm object_list -- (already displayed) 8 standard object -- (already displayed) 9 vm page queue mutex -- (already displayed) 10 pmap -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- (already displayed) 5 needsbuffer lock -- (already displayed) 7 system map -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 13 struct mount mtx -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 Softdep Lock -- (already displayed) 9 swap_pager swhash -- (already displayed) 2 tcpinp -- last acquired @ /usr/src/sys/netinet/tcp_input.c:479 6 so_snd -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 7 so_rcv -- (already displayed) 9 ifnet -- (already displayed) 3 tcp_sc_head -- last acquired @ /usr/src/sys/kern/kern_timeout.c:241 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 arc4_mtx -- (already displayed) 8 radix node head -- (already displayed) 11 rtentry -- (already displayed) 7 tcp_hc_entry -- (already displayed) 3 accept -- (already displayed) 3 so_glabel -- last acquired @ /usr/src/sys/kern/uipc_socket.c:299 8 radix node head -- (already displayed) 11 rtentry -- (already displayed) 7 tcp_hc_entry -- (already displayed) 11 arc4_mtx -- (already displayed) 5 isn_mtx -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 6 EM TX Lock -- (already displayed) 6 ip_inq -- (already displayed) 0 so_snd_sx -- last acquired @ /usr/src/sys/kern/uipc_sockbuf.c:148 6 so_snd -- (already displayed) 1 unp_global_rwlock -- last acquired @ /usr/src/sys/kern/uipc_usrreq.c:556 2 unp_mtx -- (already displayed) 3 accept -- (already displayed) 3 so_glabel -- (already displayed) 6 so_snd -- (already displayed) 3 filedesc structure -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 8 radix node head -- (already displayed) 11 rtentry -- (already displayed) 12 rts_inq -- (already displayed) 2 tcpinp -- (already displayed) 8 standard object -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- (already displayed) 7 system map -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 5 needsbuffer lock -- (already displayed) 0 pf_statetbl_lock -- last acquired @ /usr/src/sys/modules/pf/../../contrib/pf/n et/pf.c:979 10 pf task mtx -- (already displayed) 6 pfil_head_list lock -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 0 devfsmount -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops.c:691 5 devfs interlock -- (already displayed) 15 vnode_free_list -- (already displayed) 14 vnode interlock -- (already displayed) 13 struct mount mtx -- (already displayed) 15 cdev -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 UMA boot pages -- (already displayed) 1 DEVFS ruleset lock -- last acquired @ /usr/src/sys/fs/devfs/devfs_rule.c:177 8 process lock -- (already displayed) 3 user map -- (already displayed) 0 g_disk_done -- last acquired @ /usr/src/sys/geom/geom_disk.c:198 5 bio queue -- (already displayed) 12 UMA zone -- (already displayed) 0 ipqlock -- last acquired @ /usr/src/sys/netinet/ip_input.c:1086 0 semid -- last acquired @ /usr/src/sys/kern/sysv_sem.c:658 1 sem -- last acquired @ /usr/src/sys/kern/sysv_sem.c:1288 0 fdc lock -- last acquired @ /usr/src/sys/dev/fdc/fdc.c:803 0 if_afdata -- last acquired @ /usr/src/sys/net/if.c:578 0 GEOM topology -- last acquired @ /usr/src/sys/geom/geom_event.c:233 5 GEOM orphanage -- (already displayed) 5 devstat -- (already displayed) 5 unit# allocation -- (already displayed) 15 cdev -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 11 UMA boot pages -- (already displayed) 9 vm object_list -- (already displayed) 14 vnode interlock -- (already displayed) 8 standard object -- (already displayed) 7 system map -- (already displayed) 0 intr sources -- last acquired @ /usr/src/sys/amd64/amd64/intr_machdep.c:593 5 msi -- (already displayed) 0 audit_mtx -- last acquired @ /usr/src/sys/security/audit/audit_worker.c:448 0 uma object -- last acquired @ /usr/src/sys/vm/vm_meter.c:115 0 p_peers -- last acquired @ /usr/src/sys/kern/kern_exit.c:284 0 runningbufspace lock -- last acquired @ /usr/src/sys/kern/vfs_bio.c:340 0 umtxql -- last acquired @ /usr/src/sys/kern/kern_umtx.c:326 0 accept_filter_mtx -- last acquired @ /usr/src/sys/kern/uipc_accf.c:116 0 ACPI PCI bus methods -- last acquired @ /usr/src/sys/dev/acpica/acpi_pcib.c:22 1 0 rtsock route_cb lock -- last acquired @ /usr/src/sys/net/rtsock.c:191 0 rawcb -- last acquired @ /usr/src/sys/net/raw_usrreq.c:81 7 so_rcv -- (already displayed) 12 UMA zone -- (already displayed) 0 ACPI PCI link -- last acquired @ /usr/src/sys/dev/acpica/acpi_pci_link.c:432 5 ACPI semaphore -- (already displayed) 0 ACPI root bus -- last acquired @ /usr/src/sys/dev/acpica/acpi.c:1022 5 rman -- (already displayed) 5 ACPI semaphore -- (already displayed) 7 system map -- (already displayed) 0 acct_sx -- last acquired @ /usr/src/sys/kern/kern_acct.c:351 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 eventhandler -- (already displayed) 5 TID lock -- (already displayed) 9 vm object_list -- (already displayed) 7 system map -- (already displayed) 8 standard object -- (already displayed) 1 proctree -- last acquired @ /usr/src/sys/kern/kern_fork.c:571 2 allproc -- last acquired @ /usr/src/sys/kern/kern_fork.c:297 3 allprison -- last acquired @ /usr/src/sys/kern/kern_jail.c:945 11 sleep mtxpool -- (already displayed) 8 process lock -- (already displayed) 4 fdesc -- (already displayed) 3 filedesc structure -- (already displayed) 14 vnode interlock -- (already displayed) 3 user map -- (already displayed) 11 arc4_mtx -- (already displayed) 7 process group -- (already displayed) 4 Giant -- (already displayed) 8 process lock -- (already displayed) 9 session -- (already displayed) 6 sigio lock -- (already displayed) 2 clone events drain lock -- last acquired @ /usr/src/sys/fs/devfs/devfs_vnops .c:626 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 15 cdev -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 3 filedesc structure -- (already displayed) 8 process lock -- (already displayed) 5 FFS Lock -- (already displayed) 13 struct mount mtx -- (already displayed) 14 vnode interlock -- (already displayed) 5 buf queue lock -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 4 Giant -- (already displayed) 5 needsbuffer lock -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 Softdep Lock -- (already displayed) 0 vm daemon -- last acquired @ /usr/src/sys/vm/vm_pageout.c:1531 0 sysctl lock -- last acquired @ /usr/src/sys/kern/kern_sysctl.c:1396 11 arc4_mtx -- (already displayed) 2 allproc -- (already displayed) 8 process lock -- (already displayed) 3 user map -- (already displayed) 15 cdev -- (already displayed) 1 filelist lock -- last acquired @ /usr/src/sys/kern/kern_descrip.c:2179 3 filedesc structure -- (already displayed) 5 GEOM orphanage -- (already displayed) 4 Giant -- (already displayed) 9 ktrace -- (already displayed) 1 kernel linker -- last acquired @ /usr/src/sys/kern/kern_linker.c:1096 12 UMA zone -- (already displayed) 2 module subsystem sx lock -- last acquired @ /usr/src/sys/kern/kern_module.c: 407 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 3 filedesc structure -- (already displayed) 14 vnode interlock -- (already displayed) 5 Name Cache -- (already displayed) 5 buf queue lock -- (already displayed) 5 needsbuffer lock -- (already displayed) 5 vfs hash -- (already displayed) 15 vnode_free_list -- (already displayed) 13 struct mount mtx -- (already displayed) 5 dirhash list -- (already displayed) 12 vm page queue free mutex -- (already displayed) 7 system map -- (already displayed) 8 kernel object -- (already displayed) 5 bio queue -- (already displayed) 5 bdone lock -- (already displayed) 6 dirhash -- (already displayed) 15 cdev -- (already displayed) 9 vm object_list -- (already displayed) 8 standard object -- (already displayed) 5 pbuf mutex -- (already displayed) 6 buffer daemon lock -- (already displayed) 5 kobj -- (already displayed) 1 malloc -- last acquired @ /usr/src/sys/kern/kern_malloc.c:741 12 UMA zone -- (already displayed) 7 system map -- (already displayed) 5 devstat -- (already displayed) 5 ttylist -- (already displayed) 9 vm object_list -- (already displayed) 5 UMA lock -- (already displayed) 15 Syncer mtx -- (already displayed) 1 unp_global_rwlock -- (already displayed) 1 tcp -- last acquired @ /usr/src/sys/netinet/tcp_timer.c:128 2 tcpinp -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 8 radix node head -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 11 rtentry -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 6 EM TX Lock -- (already displayed) 3 accept -- (already displayed) 11 sleep mtxpool -- (already displayed) 3 so_glabel -- (already displayed) 6 ip_inq -- (already displayed) 3 tcp_sc_head -- (already displayed) 1 udp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:839 2 udpinp -- last acquired @ /usr/src/sys/netinet/udp_usrreq.c:843 3 in_multi_mtx -- last acquired @ /usr/src/sys/netinet/in_mcast.c:320 4 igmp_mtx -- last acquired @ /usr/src/sys/netinet/igmp.c:446 10 if_addr_mtx -- (already displayed) 10 if_addr_mtx -- (already displayed) 4 EM Core Lock -- last acquired @ /usr/src/sys/kern/kern_timeout.c:241 6 EM TX Lock -- (already displayed) 10 if_addr_mtx -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 UMA boot pages -- (already displayed) 7 taskqueue -- (already displayed) 6 network driver -- (already displayed) 6 so_snd -- (already displayed) 9 ifnet -- (already displayed) 11 arc4_mtx -- (already displayed) 8 radix node head -- (already displayed) 11 rtentry -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 6 EM TX Lock -- (already displayed) 7 so_rcv -- (already displayed) 3 accept -- (already displayed) 6 ip_inq -- (already displayed) 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 UMA boot pages -- (already displayed) 8 radix node head -- (already displayed) 5 PFil hook read/write mutex -- (already displayed) 11 rtentry -- (already displayed) 6 IPFW static rules -- (already displayed) 7 if send queue -- (already displayed) 6 EM TX Lock -- (already displayed) 1 rip -- last acquired @ /usr/src/sys/netinet/raw_ip.c:638 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 2 rawinp -- last acquired @ /usr/src/sys/netinet/raw_ip.c:639 7 so_rcv -- (already displayed) 5 ACPI semaphore -- (already displayed) 3 allprison -- (already displayed) 1 cpufreq lock -- last acquired @ /usr/src/sys/kern/kern_cpu.c:413 12 UMA zone -- (already displayed) 12 vm page queue free mutex -- (already displayed) 11 UMA boot pages -- (already displayed) 11 eventhandler -- (already displayed) 12 eventhandler list -- (already displayed) 9 ifnet -- (already displayed) 1 ACPI CPU -- last acquired @ /usr/src/sys/dev/acpica/acpi_cpu.c:1167 8 radix node head -- (already displayed) 14 vnode interlock -- (already displayed) 3 filedesc structure -- (already displayed) 0 ng_node -- last acquired @ order list:0 1 ng_worklist -- last acquired @ order list:0 0 802.11 com lock -- last acquired @ order list:0 0 ddp_list_mtx -- last acquired @ order list:0 1 ddp_mtx -- last acquired @ order list:0 0 slip_mtx -- last acquired @ order list:0 1 slip sc_mtx -- last acquired @ order list:0 0 unp -- last acquired @ order list:0 6 so_snd -- (already displayed) Spin locks: Locks which were never acquired: SCSI CD Changer List MD config lock IPFW dynamic rules arp_inq pfs_vncache ppp_softc_list_mtx tunmtx gif_mtx msq nfs4dev state nfs4dev waitq nfs4dev newq ntfs nthash NFS xid lock NFS reqq lock ACPI global lock CAM SIMQ lock hptlock LED sx LED mtx audit_pipe_mtx nfslock audit_trigger_mtx ktrace_sx bpin lock UUID generator mutex lock ACPI PCI power methods ACPI lid ACPI HPET support ACPI embedded controller ACPI thermal zone ACPI Smart Battery ACPI cmbat ACPI power resources ACPI generic battery ACPI AC adapter MSDOSFS fileno pmc shared lock kqueue order firmware table securelevel mutex lock encapmtx fifo mutex phys_pager list dev_pager list swapdev swap_pager list vm map sleep mutex db> show lockedvnods Locked vnodes 0xffffff001106a9b0: tag ufs, type VREG usecount 4, writecount 0, refcount 6 mountedhere 0 flags (VV_TEXT) v_object 0xffffff0011318680 ref 2 pages 35 lock type ufs: SHARED (count 1) ino 2239451, on dev ufs/usr64 0xffffff001106a3e0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0001820000 (pid 42488) ino 2262052, on dev ufs/usr64 0xffffff0001eabba0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff001106f680 (pid 42307) with 1 pending ino 2262734, on dev ufs/usr64 db> show uma Zone Size Used Free Requests pfosfp 40 407 97 407 pfospfen 112 696 30 696 pfiaddrpl 120 0 0 0 pfstatescrub 40 0 0 0 pffrcent 24 0 0 0 pffrcache 80 0 0 0 pffrag 80 0 0 0 pffrent 32 0 0 0 pfrkentry2 216 0 0 0 pfrkentry 216 2322 72 2330 pfrktable 1296 12 27 1880 pfpooladdrpl 88 12 72 12 pfaltqpl 240 0 0 0 pfstatepl 392 460 10 466 pfrulepl 912 69 15 69 pfsrctrpl 152 0 0 0 FFS2 dinode 256 1209 66 1232 FFS1 dinode 128 0 0 0 FFS inode 192 1209 51 1232 Mountpoints 808 6 9 6 SWAPMETA 288 0 0 0 IPFW dynamic rule 120 0 0 0 rtentry 240 73 55 139 ripcb 288 1 38 2 sackhole 32 0 0 0 tcpreass 40 0 0 0 hostcache 136 2 54 2 syncache 120 0 93 86 tcptw 88 19 65 19 tcpcb 728 38 27 115 inpcb 288 57 21 115 udpcb 288 23 29 743 ipq 56 0 0 0 unpcb 248 23 22 36 socket 696 99 26 899 KNOTE 120 26 67 21403 itimer 360 0 0 0 ksiginfo 112 84 972 84 pipe 744 6 34 551 NFSNODE 664 0 0 0 NFSMOUNT 568 0 0 0 DIRHASH 1024 56 12 56 NAMEI 1024 2 34 18355 L VFS Cache 327 0 0 0 S VFS Cache 104 1400 112 2069 VNODEPOLL 128 0 0 0 VNODE 496 1240 16 1264 ata_composite 352 0 0 0 ata_request 312 2 94 4738 g_bio 216 10 332 18896 ACL UMA zone 388 0 0 0 mbuf_ext_refcnt 4 0 336 60 mbuf_jumbo_16k 16384 0 0 0 mbuf_jumbo_9k 9216 0 0 0 mbuf_jumbo_pagesize 4096 0 14 36 mbuf_cluster 2048 1152 8 1152 mbuf 256 1 392 9470 mbuf_packet 256 793 359 12023 audit_record 984 0 0 0 VMSPACE 416 45 18 1009 SLEEPQUEUE 64 145 135 145 UPCALL 88 0 0 0 THREAD 824 129 15 129 PROC 1128 96 36 1060 umtx pi 96 0 0 0 TURNSTILE 152 145 23 145 Files 120 239 102 8378 4096 4096 382 37 4229 2048 2048 65 85 2246 1024 1024 62 150 3212 512 512 625 26 6508 256 256 790 80 6895 128 128 9011 153 16531 64 64 1988 196 51814 32 32 2139 285 3341 16 16 1685 331 33999 mt_zone 1024 217 7 217 DP fakepg 120 0 0 0 MAP ENTRY 112 5149 1748 42364 KMAP ENTRY 112 36 96 1495 MAP 248 7 23 7 VM OBJECT 208 2182 122 17689 128 Bucket 1048 43 2 43 64 Bucket 536 42 0 42 32 Bucket 280 59 11 59 16 Bucket 152 80 20 80 UMA Hash 256 6 9 7 UMA RCntSlabs 128 594 15 594 UMA Slabs 128 674 22 1224 UMA Zones 216 89 13 89 UMA Kegs 216 89 13 89 db> show malloc Type InUse MemUse Requests msdosfs_mount 0 0K 0 msdosfs_fat 0 0K 0 msdosfs_fileno 0 0K 0 msdosfs_node 0 0K 0 DEVFS 27 1K 28 DEVFS_RULE 36 17K 36 DEVFS2 108 2K 108 DEVFS3 244 61K 245 DEVFS1 111 56K 111 USB 91 20K 106 USBdev 21 9K 21 atkbddev 2 1K 2 USBHC 0 0K 0 UART 0 0K 0 nexusdev 4 1K 4 msi 2 1K 2 twe_commands 0 0K 0 twa_commands 0 0K 0 firewire 0 0K 0 legacydrv 0 0K 0 io_apic 1 2K 1 entropy 1024 64K 1024 ppbusdev 3 1K 3 fw_xfer 0 0K 0 memdesc 1 4K 1 madt_table 0 0K 0 scsi_cd 0 0K 0 CAM ccb queue 0 0K 0 vm_pgdata 1 128K 1 acpipwr 0 0K 0 aaccam 0 0K 0 acpi_perf 0 0K 0 UMAHash 1 1K 1 ufs_mount 12 30K 12 ufs_quota 0 0K 0 ufs_dirhash 51 10K 51 pagedep 9 65K 24 inodedep 63 528K 89 newblk 1 1K 5144 bmsafemap 11 2K 18 allocdirect 41 11K 222 indirdep 6 1K 10 allocindir 4634 580K 4921 freefrag 1 1K 373 freeblks 12 3K 17 freefile 12 1K 22 diradd 32 2K 59 mkdir 4 1K 12 dirrem 12 1K 42 newdirblk 0 0K 0 savedino 0 0K 11 audit_trigger 0 0K 0 audit_pipe 0 0K 0 audit_pipeent 0 0K 0 audit_pipe_preselect 0 0K 0 audit_evclass 150 5K 187 audit_bsm 0 0K 0 audit_cred 0 0K 0 audit_data 0 0K 0 audit_path 0 0K 0 audit_text 0 0K 0 rpcclnt 0 0K 0 agp 0 0K 0 nfss_srvsock 0 0K 0 nfss_srvdesc 0 0K 0 nfss_daemon 1 16K 1 nfsclient_lock 0 0K 0 nfsclient_nlminfo 0 0K 0 nfsclient_req 0 0K 0 nfsclient_bigfh 0 0K 0 nfsclient_diroff 0 0K 0 nfsclient_hash 0 0K 0 nfsclient_directio 0 0K 0 nfsclient_srvsock 0 0K 0 idmap 0 0K 0 nfs4_dev 0 0K 0 syncache 1 100K 1 tcplog 0 0K 0 aacbuf 0 0K 0 hostcache 1 36K 1 IpFw/IpAcct 697 78K 697 ipfw_tbl 31 8K 31 encap_export_host 0 0K 0 dummynet 54 108K 54 in_multi 4 1K 4 ip_moptions 0 0K 0 in_msource 0 0K 0 igmp 0 0K 0 routetbl 341 97K 4442 pci_link 16 2K 16 tun 0 0K 0 SCSI SES 0 0K 0 sl 0 0K 0 ppp 0 0K 0 lo 1 1K 1 gif 0 0K 0 fw_com 0 0K 0 faith 0 0K 0 arpcom 3 1K 3 clone 6 24K 6 ifnet 7 13K 7 ifaddr 52 17K 52 ether_multi 17 1K 20 BPF 14 74K 15 subr_export_host 0 0K 0 SCSI sa 0 0K 0 mount 84 4K 138 vnodemarker 0 0K 29 vnodes 1 1K 1 vfs_hash 1 512K 1 export_host 0 0K 0 cl_savebuf 0 0K 72 vfscache 1 1024K 1 biobuf 17 34K 87 soname 8 1K 1326 pcb 24 9K 39 CAM XPT 10 2K 25 mbuf_tag 30 3K 18347 accf 0 0K 0 ptys 1 1K 1 ttys 513 85K 731 shm 6 26K 8 sem 4 8K 4 msg 4 30K 4 ioctlops 0 0K 3983 select 0 0K 0 iov 0 0K 3038 acpicmbat 0 0K 0 acpidev 63 4K 63 ciss_data 0 0K 0 CAM periph 2 1K 9 Unitno 7 1K 9 taskqueue 15 2K 15 stack 0 0K 0 CAM SIM 1 1K 1 scsi_da 0 0K 0 sbuf 0 0K 450 scsi_ch 0 0K 0 rman 161 20K 611 acpisem 12 2K 12 mfibuf 0 0K 0 kobj 227 908K 311 md_disk 0 0K 0 eventhandler 68 6K 68 devstat 16 33K 16 bus 961 75K 4819 bus-sc 66 83K 2400 md_sectors 0 0K 0 SWAP 0 0K 0 p1003.1b 1 1K 1 umtx 144 18K 144 sysctl 0 0K 192 sysctloid 2817 138K 2817 sysctltmp 0 0K 175 LED 0 0K 0 plimit 7 2K 412 uidinfo 9 3K 18 cred 34 9K 2477 pgrp 22 3K 26 session 22 3K 24 proc 2 16K 2 subproc 230 455K 1194 kbdmux 6 9K 6 mtx_pool 1 8K 1 ipsbuf 0 0K 0 module 353 45K 353 iirbuf 0 0K 0 cache 0 0K 0 devbuf 314 1777K 321 temp 34 8K 4594 ip6opt 0 0K 0 ip6ndp 0 0K 0 CAM queue 3 1K 3 free 0 0K 0 lockf 3 1K 10 linker 96 132K 125 CAM dev queue 1 1K 1 KTRACE 100 13K 100 ast_driver 0 0K 0 afd_driver 0 0K 0 prison 0 0K 0 ithread 76 13K 76 acd_driver 0 0K 0 zombie 0 0K 0 proc-args 28 3K 401 kqueue 34 39K 54 kenv 71 11K 73 filedesc 102 64K 1074 filedesc_to_leader 0 0K 0 sigio 1 1K 1 ar_driver 0 0K 10 ata_pci 0 0K 0 cdev 24 6K 24 sbp 0 0K 0 if_fwip 0 0K 0 ata_dma 2 1K 2 if_fwe 0 0K 0 ad_driver 2 1K 2 ata_generic 2 2K 2 acpitask 0 0K 1 isofs_mount 0 0K 0 isofs_node 0 0K 0 isadev 5 1K 5 acpica 1865 180K 58648 GEOM 144 25K 1163 fwmem 0 0K 0 pfs_vncache 0 0K 0 pfs_nodes 20 5K 20 ntfs_mount 0 0K 0 ntfs_ntnode 0 0K 0 ntfs_fnode 0 0K 0 ntfs_dir 0 0K 0 ntfs_vattr 0 0K 0 ntfsd_resdata 0 0K 0 ntfs_vrun 0 0K 0 ntfs_decomp 0 0K 0 ntfs_nthash 1 512K 1 db> cont Starting background file system checks in 60 seconds. --uAKRQypu60I7Lcqm-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 11:38:59 2008 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 644E0106564A for ; Sat, 22 Mar 2008 11:38:59 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1828FC16 for ; Sat, 22 Mar 2008 11:38:59 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at inter-sonic.com Message-ID: <47E4EB66.6070802@intersonic.se> Date: Sat, 22 Mar 2008 12:20:06 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: is iwi supposed to work on 7-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: Sat, 22 Mar 2008 11:38:59 -0000 Hi, Have Thinkpad T42 with 2200 wireless that USED to work with if_iwi and 7-STABLE, now regardless of what I do I cannot associate with access points (works with XP). Are there any changes made that I cannot see during the last few months that changed operation? Have setup loader.conf according to man page. Thanks for any hints, --per From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 13:34:41 2008 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 CE6F0106564A for ; Sat, 22 Mar 2008 13:34:41 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id B8AD28FC14 for ; Sat, 22 Mar 2008 13:34:41 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so2160479waf.3 for ; Sat, 22 Mar 2008 06:34:41 -0700 (PDT) Received: by 10.114.144.1 with SMTP id r1mr7923179wad.53.1206191371947; Sat, 22 Mar 2008 06:09:31 -0700 (PDT) Received: by 10.114.27.6 with HTTP; Sat, 22 Mar 2008 06:09:31 -0700 (PDT) Message-ID: Date: Sat, 22 Mar 2008 14:09:31 +0100 From: "TooMany Secrets" To: freebsd-stable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Subject: Error compiling buildworld 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, 22 Mar 2008 13:34:41 -0000 SGkhCgpNeSBzeXN0ZW06CgpGcmVlQlNEIHRvb21hbnkudG9vbWFueS5uZXQgNy4wLVJFTEVBU0Ug RnJlZUJTRCA3LjAtUkVMRUFTRSAjMTogVGh1Ck1hciAyMCAyMDo0NjoyMSBDRVQgMjAwOApyb290 QHRvb21hbnkudG9vbWFueS5uZXQ6L3Vzci9vYmovdXNyL3NyYy9zeXMvVE9PTUFOWSAgaTM4NgoK U3lzdGVtIGNzdXAgZnJvbSB0b2RheSBhdCAxMzoyMCAoYXByb3guKS4KCk15IG1ha2UuY29uZiBm bGFnczoKQ1BVVFlQRT89cHJlc2NvdHQKQ0ZMQUdTPSAtTyAtcGlwZQpDWFhGTEFHUys9IC1PIC1E Tk9fTUFMTE9DX0VYVFJBUwpDT1BURkxBR1M9IC1PIC1waXBlCiNDQ0FDSEUKQ0M9L3Vzci9sb2Nh bC9saWJleGVjL2NjYWNoZS93b3JsZC1jYwpDWFg9L3Vzci9sb2NhbC9saWJleGVjL2NjYWNoZS93 b3JsZC1jKysKKEkgdHJ5IHdpdGggYW5kIHdpdGhvdXQgY2NhY2hlKS4KClRoZW4sIHdoZW4gSSBj b21waWxlICh3aXRoIG9yIHdpdGhvdXQgYW55IENGTEFHKSB0aGUgY29tcGlsYXRpb24gZmFpbHMK d2l0aCB0aGlzIGVycm9yIChpbiBidWlsZHdvcmxkIHBhcnQpOgoKc2ggL3Vzci9zcmMvdG9vbHMv aW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgY3J0YmVnaW4ubwovdXNyL29iai91 c3Ivc3JjL3RtcC91c3IvbGliL2NydGJlZ2luLm8Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5z aCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgY3J0ZW5kLm8KL3Vzci9vYmovdXNyL3NyYy90bXAv dXNyL2xpYi9jcnRlbmQubwpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcg d2hlZWwgLW0gNDQ0ICBjcnRiZWdpblQubwovdXNyL29iai91c3Ivc3JjL3RtcC91c3IvbGliL2Ny dGJlZ2luVC5vCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAt bSA0NDQgIGNydGJlZ2luLlNvCi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvY3J0YmVnaW5T Lm8Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAg Y3J0ZW5kLlNvCi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvY3J0ZW5kUy5vCj09PT4gbGli L2NzdS9pMzg2LWVsZiAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkKcm0gLWYgLmRlcGVuZApDQz0n L3Vzci9sb2NhbC9saWJleGVjL2NjYWNoZS93b3JsZC1jYycgbWtkZXAgLWYgLmRlcGVuZCAtYQot SS91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYvLi4vY29tbW9uIC1JL3Vzci9zcmMvbGliL2NzdS9p Mzg2LWVsZgovLi4vLi4vbGliYy9pbmNsdWRlIC91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYvY3J0 MS5jCi91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYvY3J0aS5TIC91c3Ivc3JjL2xpYi9jc3UvaTM4 Ni1lbGYvY3J0bi5TCi91c3IvbG9jYWwvbGliZXhlYy9jY2FjaGUvd29ybGQtY2MgLU8gLXBpcGUg LW1hcmNoPXByZXNjb3R0Ci1JL3Vzci9zcmMvbGliL2NzdS9pMzg2LWVsZi8uLi9jb21tb24gIC1J L3Vzci9zcmMvbGliL2NzdS9pMzg2LWVsZi8uCi4vLi4vbGliYy9pbmNsdWRlIC1Xc3lzdGVtLWhl YWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XCi1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0 cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pCm50ZXItYXJpdGggLVdy ZXR1cm4tdHlwZSAtV2Nhc3QtcXVhbCAtV3dyaXRlLXN0cmluZ3MgLVdzd2l0Y2ggLVdzaGFkb3cK LVdjYXN0LWFsaWduIC1XdW51c2VkLXBhcmFtZXRlciAtV2NoYXItc3Vic2NyaXB0cyAtV2lubGlu CmUgLVduZXN0ZWQtZXh0ZXJucyAtV3JlZHVuZGFudC1kZWNscyAtV25vLXBvaW50ZXItc2lnbiAt YwovdXNyL3NyYy9saWIvY3N1L2kzODYtZWxmL2NydDEuYwpjYzE6IGVycm9yOiB1bnJlY29nbml6 ZWQgY29tbWFuZCBsaW5lIG9wdGlvbiAiLVdjaGFyLXN1YnNjcmlwdHMiCioqKiBFcnJvciBjb2Rl IDEKClN0b3AgaW4gL3Vzci9zcmMvbGliL2NzdS9pMzg2LWVsZi4KKioqIEVycm9yIGNvZGUgMQoK U3RvcCBpbiAvdXNyL3NyYy4KKioqIEVycm9yIGNvZGUgMQoKU3RvcCBpbiAvdXNyL3NyYy4KKioq IEVycm9yIGNvZGUgMQoKU3RvcCBpbiAvdXNyL3NyYy4KKioqIEVycm9yIGNvZGUgMQoKU3RvcCBp biAvdXNyL3NyYy4KCkFueWJvZHkgY291bGQgaGVscCBtZSwgcGxlYXNlPwoKVGhhbmsgeW91IQoK LS0gCkhhdmUgYSBuaWNlIGRheSA7LSkKVG9vTWFueVNlY3JldHMKCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KRGlqbyBDb25mdWNpbzoKIkV4w61nZXRlIG11Y2hvIGEgdGkgbWlzbW8geSBl c3BlcmEgcG9jbyBkZSBsb3MgZGVtw6FzLiBBc8OtIHRlIGFob3JyYXLDoXMKZGlzZ3VzdG9zLiIK PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo= From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 14:20:52 2008 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 A996B1065670 for ; Sat, 22 Mar 2008 14:20:52 +0000 (UTC) (envelope-from wwdevil@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 853FB8FC1E for ; Sat, 22 Mar 2008 14:20:52 +0000 (UTC) (envelope-from wwdevil@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1179036rvb.43 for ; Sat, 22 Mar 2008 07:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ccl1luOXIC5jfvq6h2gmA4aHU9HBK/K4ssWdDzG30EU=; b=rz/x7aEm9F65sdTb/jGVsP/9F74ujklfmyRB3uid0WRkc3BSLPbvLBYeb6wmdBgnfu6FYoaW1BmyBpIoNLj9qHj8zHTJp5JMuFhFQJzcUEoy4SFr8vK0WvvaBU1b6XGid436kpRScIlOuZHQXJ35inRstimgspknozlve9s/tn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QTpAhXNt+m4xnd+nGmXtruSRBP1TKf2+KZ9u9ZySEB77ogY7rU4a+gUwYa9eZd/qYKafPshnLO6GCNxU3Bijb71ZGo5Y2mCuzLcgmk3UHG4GP0TqA0Ia3etGzIimOWQ/JZCDwBaqdBQO9mptaLG9olEkseomnZkvBpQf8KDtKqM= Received: by 10.141.86.14 with SMTP id o14mr1709581rvl.148.1206193964057; Sat, 22 Mar 2008 06:52:44 -0700 (PDT) Received: by 10.141.43.20 with HTTP; Sat, 22 Mar 2008 06:52:44 -0700 (PDT) Message-ID: <31ee4d090803220652wdd9659cxcac3eded850931e3@mail.gmail.com> Date: Sat, 22 Mar 2008 19:52:44 +0600 From: "wDevil wDevil" To: freebsd-stable@freebsd.org In-Reply-To: <31ee4d090803220651y7c29491ehc1a9880a13669c5c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E4EB66.6070802@intersonic.se> <31ee4d090803220651y7c29491ehc1a9880a13669c5c@mail.gmail.com> Subject: Fwd: is iwi supposed to work on 7-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: Sat, 22 Mar 2008 14:20:52 -0000 2008/3/22, Per olof Ljungmark : > Hi, > > Have Thinkpad T42 with 2200 wireless that USED to work with if_iwi and > 7-STABLE, now regardless of what I do I cannot associate with access > points (works with XP). Are there any changes made that I cannot see > during the last few months that changed operation? Have setup > loader.conf according to man page. > > Thanks for any hints, > > --per > _______________________________________________ > 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" > i have th same problem. iwi won't work with dhclient. after: "dhclient iwi0" - iwi0: firmware stuck in state 4. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 14:35:46 2008 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 031DC1065670 for ; Sat, 22 Mar 2008 14:35:46 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id F0C7F8FC20 for ; Sat, 22 Mar 2008 14:35:45 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id C41BF1CC06B; Sat, 22 Mar 2008 07:35:45 -0700 (PDT) Date: Sat, 22 Mar 2008 07:35:45 -0700 From: Jeremy Chadwick To: John Pettitt Message-ID: <20080322143545.GA31702@eos.sc1.parodius.com> References: <47E4B1BC.6020005@cloudview.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E4B1BC.6020005@cloudview.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: 7-STABLE not seeing second em interface on supermicro mb 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, 22 Mar 2008 14:35:46 -0000 On Sat, Mar 22, 2008 at 12:14:04AM -0700, John Pettitt wrote: > I just installed 7-STABLE on a new dual/quad machine based on a supermicro > motherboard - it works fine except that it's not seeing the second network > interface (em driver) - is there a magic incantation to make this work? What Supermicro system or motherboard is this? I have many, so I can confirm/deny what you're seeing on other systems. > Where should I start debugging this ? Start with: 1) the BIOS -- you can enable/disable NICs there. If both show enabled, try Load Setup Defaults to make sure there's no CMOS corruption (sometimes this happens when upgrading BIOSes, and may have happened at the factory -- who knows). 2) Jumpers on the motherboard -- many Supermicro boards have actual jumpers on the board to disable either NICs, in addition to the BIOS option. Check these. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 14:42:44 2008 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 09506106566B for ; Sat, 22 Mar 2008 14:42:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 022D48FC16 for ; Sat, 22 Mar 2008 14:42:43 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id DC2171CC068; Sat, 22 Mar 2008 07:42:43 -0700 (PDT) Date: Sat, 22 Mar 2008 07:42:43 -0700 From: Jeremy Chadwick To: TooMany Secrets Message-ID: <20080322144243.GB31702@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 14:42:44 -0000 On Sat, Mar 22, 2008 at 02:09:31PM +0100, TooMany Secrets wrote: > System csup from today at 13:20 (aprox.). > > My make.conf flags: > CPUTYPE?=prescott > CFLAGS= -O -pipe > CXXFLAGS+= -O -DNO_MALLOC_EXTRAS > COPTFLAGS= -O -pipe > #CCACHE > CC=/usr/local/libexec/ccache/world-cc > CXX=/usr/local/libexec/ccache/world-c++ > (I try with and without ccache). > CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a > -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf > /../../libc/include /usr/src/lib/csu/i386-elf/crt1.c > /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > /usr/local/libexec/ccache/world-cc -O -pipe -march=prescott > -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/. > ./../libc/include -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi > nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wcast-align -Wunused-parameter -Wchar-subscripts -Winlin > e -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c > /usr/src/lib/csu/i386-elf/crt1.c > cc1: error: unrecognized command line option "-Wchar-subscripts" There haven't been any changes to src/lib/csu/i386-elf in 2-4 years: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/csu/i386-elf/ I'm willing to bet that the compiler tinkering you've done is causing said problem. It would indicate whatever compiler is being used ("world-cc") is acting as if it doesn't understand the compiler flag specified. I can assure you that gcc does support this option. It would be useful to see see the buildworld output with CXXFLAGS, COPTFLAGS, CC, and CXX disabled in your make.conf. I realise you said "I get the same error without this stuf", but you should've sent *that* buildworld output. :-) Also, you really should be using "?=" operators on those optimisation flags, in case something else overrides them. Yes, I know what the documentation in share/examples/etc/make.conf says, but I still recommend doing what I said. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 14:44:28 2008 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 71C121065670 for ; Sat, 22 Mar 2008 14:44:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 81C8A8FC14; Sat, 22 Mar 2008 14:44:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E51B50.1070407@FreeBSD.org> Date: Sat, 22 Mar 2008 15:44:32 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ken Chen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.0 kernel panic on Intel SR2400 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, 22 Mar 2008 14:44:28 -0000 Ken Chen wrote: > Hello, > > I upgrade from 6.2 to 7.0 on this Intel SR2400 server, then it panic after > mounting storage when boot with 7.0 kernel. > > I don't leave enough space for core dumping, so I should get nothing more > for the panic. Any way to gather enough information for bug reporting? Configure DDB in the kernel and then obtain a backtrace from the panic, and either hand-transcribe or take a photo of it. See the developers handbook for detailed instructions. Kris From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 15:19:33 2008 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 D2FBF1065675 for ; Sat, 22 Mar 2008 15:19:33 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id BCE608FC21 for ; Sat, 22 Mar 2008 15:19:33 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so2202182waf.3 for ; Sat, 22 Mar 2008 08:19:31 -0700 (PDT) Received: by 10.114.154.1 with SMTP id b1mr8172173wae.34.1206199171574; Sat, 22 Mar 2008 08:19:31 -0700 (PDT) Received: by 10.114.27.6 with HTTP; Sat, 22 Mar 2008 08:19:31 -0700 (PDT) Message-ID: Date: Sat, 22 Mar 2008 16:19:31 +0100 From: "TooMany Secrets" To: "Jeremy Chadwick" In-Reply-To: <20080322144243.GB31702@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080322144243.GB31702@eos.sc1.parodius.com> Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 15:19:33 -0000 T24gU2F0LCBNYXIgMjIsIDIwMDggYXQgMzo0MiBQTSwgSmVyZW15IENoYWR3aWNrIDxrb2l0c3VA ZnJlZWJzZC5vcmc+IHdyb3RlOgo+ICA+IE15IG1ha2UuY29uZiBmbGFnczoKPiAgPiBDUFVUWVBF Pz1wcmVzY290dAo+ICA+IENGTEFHUz0gLU8gLXBpcGUKPiAgPiBDWFhGTEFHUys9IC1PIC1ETk9f TUFMTE9DX0VYVFJBUwo+ICA+IENPUFRGTEFHUz0gLU8gLXBpcGUKPiAgPiAjQ0NBQ0hFCj4gID4g Q0M9L3Vzci9sb2NhbC9saWJleGVjL2NjYWNoZS93b3JsZC1jYwo+ICA+IENYWD0vdXNyL2xvY2Fs L2xpYmV4ZWMvY2NhY2hlL3dvcmxkLWMrKwo+ICA+IChJIHRyeSB3aXRoIGFuZCB3aXRob3V0IGNj YWNoZSkuCj4gIEknbSB3aWxsaW5nIHRvIGJldCB0aGF0IHRoZSBjb21waWxlciB0aW5rZXJpbmcg eW91J3ZlIGRvbmUgaXMgY2F1c2luZwo+ICBzYWlkIHByb2JsZW0uICBJdCB3b3VsZCBpbmRpY2F0 ZSB3aGF0ZXZlciBjb21waWxlciBpcyBiZWluZyB1c2VkCj4gICgid29ybGQtY2MiKSBpcyBhY3Rp bmcgYXMgaWYgaXQgZG9lc24ndCB1bmRlcnN0YW5kIHRoZSBjb21waWxlciBmbGFnCj4gIHNwZWNp ZmllZC4gIEkgY2FuIGFzc3VyZSB5b3UgdGhhdCBnY2MgZG9lcyBzdXBwb3J0IHRoaXMgb3B0aW9u LgoKSXQgaXMgdGhlIGdjYyBvZiB0aGUgc3lzdGVtISBIb3cgaXMgcG9zc2libGUgdGhhdCBnY2Mg ZnJvbSBmYnNkIDcuMApkb2Vzbid0IHVuZGVyc3RhbmQgYSBjb21waWxlciBmbGFnIGZyb20gZmJz ZCA3LjAgc291cmNlcz8gRXhjdXNlLCBidXQKSSdtIGEgYml0IG5ld2JpZS4uLgoKPiAgSXQgd291 bGQgYmUgdXNlZnVsIHRvIHNlZSBzZWUgdGhlIGJ1aWxkd29ybGQgb3V0cHV0IHdpdGggQ1hYRkxB R1MsCj4gIENPUFRGTEFHUywgQ0MsIGFuZCBDWFggZGlzYWJsZWQgaW4geW91ciBtYWtlLmNvbmYu ICBJIHJlYWxpc2UgeW91IHNhaWQKPiAgIkkgZ2V0IHRoZSBzYW1lIGVycm9yIHdpdGhvdXQgdGhp cyBzdHVmIiwgYnV0IHlvdSBzaG91bGQndmUgc2VudCAqdGhhdCoKPiAgYnVpbGR3b3JsZCBvdXRw dXQuICA6LSkKCklzIHRoZSBzYW1lIG91dHB1dC4KCj4gIEFsc28sIHlvdSByZWFsbHkgc2hvdWxk IGJlIHVzaW5nICI/PSIgb3BlcmF0b3JzIG9uIHRob3NlIG9wdGltaXNhdGlvbgo+ICBmbGFncywg aW4gY2FzZSBzb21ldGhpbmcgZWxzZSBvdmVycmlkZXMgdGhlbS4gIFllcywgSSBrbm93IHdoYXQg dGhlCj4gIGRvY3VtZW50YXRpb24gaW4gc2hhcmUvZXhhbXBsZXMvZXRjL21ha2UuY29uZiBzYXlz LCBidXQgSSBzdGlsbAo+ICByZWNvbW1lbmQgZG9pbmcgd2hhdCBJIHNhaWQuCgpIdW1tbS4uLiB3 aGlsZSB5b3UsIG9yIGFueWJvZHksIGNvdWxkIHNheSBtZSBhbnl0aGluZyBhYm91dCB0aGlzLCBJ CnRyeSB3aXRoIHRoZSAiPz0iIG9wZXJhdG9yLCBidXQgaWYgd2l0aG91dCBvcGVyYXRvcnMgZG9l c24ndApjb21waWxlLi4uCgpUaGFuayB5b3UgSmVyZW15LgoKLS0gCkhhdmUgYSBuaWNlIGRheSA7 LSkKVG9vTWFueVNlY3JldHMKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0KRGlqbyBDb25m dWNpbzoKIkV4w61nZXRlIG11Y2hvIGEgdGkgbWlzbW8geSBlc3BlcmEgcG9jbyBkZSBsb3MgZGVt w6FzLiBBc8OtIHRlIGFob3JyYXLDoXMKZGlzZ3VzdG9zLiIKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PQo= From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 15:31:36 2008 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 48B971065677 for ; Sat, 22 Mar 2008 15:31:36 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 038F68FC27 for ; Sat, 22 Mar 2008 15:31:34 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so2206843waf.3 for ; Sat, 22 Mar 2008 08:31:34 -0700 (PDT) Received: by 10.114.150.1 with SMTP id x1mr8117782wad.109.1206199894585; Sat, 22 Mar 2008 08:31:34 -0700 (PDT) Received: by 10.114.27.6 with HTTP; Sat, 22 Mar 2008 08:31:34 -0700 (PDT) Message-ID: Date: Sat, 22 Mar 2008 16:31:34 +0100 From: "TooMany Secrets" To: "Jeremy Chadwick" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080322144243.GB31702@eos.sc1.parodius.com> Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 15:31:36 -0000 T24gU2F0LCBNYXIgMjIsIDIwMDggYXQgNDoxOSBQTSwgVG9vTWFueSBTZWNyZXRzIDx0b29tYW55 QHRvb21hbnkubmV0PiB3cm90ZToKPiAgPiAgQWxzbywgeW91IHJlYWxseSBzaG91bGQgYmUgdXNp bmcgIj89IiBvcGVyYXRvcnMgb24gdGhvc2Ugb3B0aW1pc2F0aW9uCj4gID4gIGZsYWdzLCBpbiBj YXNlIHNvbWV0aGluZyBlbHNlIG92ZXJyaWRlcyB0aGVtLiAgWWVzLCBJIGtub3cgd2hhdCB0aGUK PiAgPiAgZG9jdW1lbnRhdGlvbiBpbiBzaGFyZS9leGFtcGxlcy9ldGMvbWFrZS5jb25mIHNheXMs IGJ1dCBJIHN0aWxsCj4gID4gIHJlY29tbWVuZCBkb2luZyB3aGF0IEkgc2FpZC4KPgo+ICBIdW1t bS4uLiB3aGlsZSB5b3UsIG9yIGFueWJvZHksIGNvdWxkIHNheSBtZSBhbnl0aGluZyBhYm91dCB0 aGlzLCBJCj4gIHRyeSB3aXRoIHRoZSAiPz0iIG9wZXJhdG9yLCBidXQgaWYgd2l0aG91dCBvcGVy YXRvcnMgZG9lc24ndAo+ICBjb21waWxlLi4uCgpPaywgd2l0aCAiPz0iIG9wZXJhdG9yIEknbSBv YnRhaW5pbmcgdGhlIHNhbWUgZXJyb3Igb3V0cHV0LgoKLS0gCkhhdmUgYSBuaWNlIGRheSA7LSkK VG9vTWFueVNlY3JldHMKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0KRGlqbyBDb25mdWNp bzoKIkV4w61nZXRlIG11Y2hvIGEgdGkgbWlzbW8geSBlc3BlcmEgcG9jbyBkZSBsb3MgZGVtw6Fz LiBBc8OtIHRlIGFob3JyYXLDoXMKZGlzZ3VzdG9zLiIKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PQo= From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 15:40:39 2008 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 DB5DE106566C for ; Sat, 22 Mar 2008 15:40:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id C70E18FC15 for ; Sat, 22 Mar 2008 15:40:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 839A81CC06C; Sat, 22 Mar 2008 08:40:39 -0700 (PDT) Date: Sat, 22 Mar 2008 08:40:39 -0700 From: Jeremy Chadwick To: TooMany Secrets Message-ID: <20080322154039.GA33018@eos.sc1.parodius.com> References: <20080322144243.GB31702@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 15:40:40 -0000 On Sat, Mar 22, 2008 at 04:19:31PM +0100, TooMany Secrets wrote: > On Sat, Mar 22, 2008 at 3:42 PM, Jeremy Chadwick wrote: > > > My make.conf flags: > > > CPUTYPE?=prescott > > > CFLAGS= -O -pipe > > > CXXFLAGS+= -O -DNO_MALLOC_EXTRAS > > > COPTFLAGS= -O -pipe > > > #CCACHE > > > CC=/usr/local/libexec/ccache/world-cc > > > CXX=/usr/local/libexec/ccache/world-c++ > > > (I try with and without ccache). > > I'm willing to bet that the compiler tinkering you've done is causing > > said problem. It would indicate whatever compiler is being used > > ("world-cc") is acting as if it doesn't understand the compiler flag > > specified. I can assure you that gcc does support this option. > > It is the gcc of the system! How is possible that gcc from fbsd 7.0 > doesn't understand a compiler flag from fbsd 7.0 sources? Excuse, but > I'm a bit newbie... No, because the flag in question works fine RELENG_6 and RELENG_7, using the stock (base system) gcc: $ uname -mnrs FreeBSD eos.sc1.parodius.com 6.3-PRERELEASE i386 $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 $ echo 'int main(void) { return 0; }' > tmp.c $ gcc -Wchar-subscripts -o x tmp.c $ $ uname -mnrs FreeBSD icarus.home.lan 7.0-STABLE amd64 $ gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ echo 'int main(void) { return 0; }' > tmp.c $ gcc -Wchar-subscripts -o x tmp.c $ > > It would be useful to see see the buildworld output with CXXFLAGS, > > COPTFLAGS, CC, and CXX disabled in your make.conf. I realise you said > > "I get the same error without this stuf", but you should've sent *that* > > buildworld output. :-) > > Is the same output. It can't be. You're redefining CC in make.conf, for example, so this output would not be the same: CC='/usr/local/libexec/ccache/world-cc' {...} /usr/local/libexec/ccache/world-cc {...} I don't mean to sound anal about it, but there's definitely something unique your system which is causing this; choosing a separate compiler or compiler wrapper is the most obvious cause. > > Also, you really should be using "?=" operators on those optimisation > > flags, in case something else overrides them. Yes, I know what the > > documentation in share/examples/etc/make.conf says, but I still > > recommend doing what I said. > > Hummm... while you, or anybody, could say me anything about this, I > try with the "?=" operator, but if without operators doesn't > compile... I should note that use of ?= won't fix your reported problem with -Wchar-subscripts. I was just pointing out that you should use it to allow programs to override your settings -- because there are many cases where programs use specific CFLAGS to build things correctly. Overriding them can break that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 15:56:51 2008 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 C473A1065675 for ; Sat, 22 Mar 2008 15:56:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5FAF58FC1E for ; Sat, 22 Mar 2008 15:56:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-001-036.pools.arcor-ip.net [88.66.1.36]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Jd65R01mM-0008PD; Sat, 22 Mar 2008 16:56:49 +0100 Received: (qmail 49744 invoked from network); 22 Mar 2008 15:56:03 -0000 Received: from myhost.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 22 Mar 2008 15:56:03 -0000 From: Max Laier Organization: FreeBSD To: Alex Popa Date: Sat, 22 Mar 2008 16:55:28 +0100 User-Agent: KMail/1.9.7 References: <20080314192359.GA4677@dataxnet.ro> <200803152217.02568.max@love2party.net> <20080322102933.GA76747@dataxnet.ro> In-Reply-To: <20080322102933.GA76747@dataxnet.ro> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_wvS5Hdzr8z13U66" Message-Id: <200803221655.28975.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/v5WXM4ReteacTnmVpYFcrswHEMS+JCLwqXzR gnnhn1f737KYgKZtTyeojevU26mSAl0dm8JWz96rf4T5bcsFKS fpoAHJTxhbrwla2di5Jrg== Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces) 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, 22 Mar 2008 15:56:51 -0000 --Boundary-00=_wvS5Hdzr8z13U66 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, On Saturday 22 March 2008 11:29:33 Alex Popa wrote: > Sorry for the big delay, but here are the traces you requested. don't worry, you are a great help! Could you try the attached patch? I missed the fact that you are using FASTROUTE in your setup. There is obviously a problem with it, but the attached patch should work around that. The other LOR really is harmless and rather an oversight in WITNESS: a LOR with a shared/read lock can't cause a deadlock (unless there is also a LOR with the same lock in exclusive mode). But this is rather complex to check and might not be easily implemented in WITNESS. Anyways - I believe this patch should work around your problem. Let us know your findings - thanks. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-00=_wvS5Hdzr8z13U66 Content-Type: text/x-diff; charset="utf-8"; name="pf_route.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf_route.diff" Index: pf.c =================================================================== RCS file: /home/mlaier/fcvs/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.51 diff -u -r1.51 pf.c --- pf.c 21 Nov 2007 10:12:52 -0000 1.51 +++ pf.c 22 Mar 2008 15:42:18 -0000 @@ -6106,7 +6106,13 @@ dst->sin_addr = ip->ip_dst; if (r->rt == PF_FASTROUTE) { +#ifdef __FreeBSD__ + PF_UNLOCK(); +#endif rtalloc(ro); +#ifdef __FreeBSD__ + PF_LOCK(); +#endif if (ro->ro_rt == 0) { ipstat.ips_noroute++; goto bad; --Boundary-00=_wvS5Hdzr8z13U66-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 16:08:59 2008 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 2339D106564A for ; Sat, 22 Mar 2008 16:08:59 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.249]) by mx1.freebsd.org (Postfix) with ESMTP id E0BC18FC2C for ; Sat, 22 Mar 2008 16:08:58 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by hs-out-0708.google.com with SMTP id m63so1527451hsc.11 for ; Sat, 22 Mar 2008 09:08:58 -0700 (PDT) Received: by 10.115.54.1 with SMTP id g1mr8163986wak.136.1206202137049; Sat, 22 Mar 2008 09:08:57 -0700 (PDT) Received: by 10.114.27.6 with HTTP; Sat, 22 Mar 2008 09:08:57 -0700 (PDT) Message-ID: Date: Sat, 22 Mar 2008 17:08:57 +0100 From: "TooMany Secrets" To: "Jeremy Chadwick" In-Reply-To: <20080322154039.GA33018@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080322144243.GB31702@eos.sc1.parodius.com> <20080322154039.GA33018@eos.sc1.parodius.com> Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 16:08:59 -0000 T24gU2F0LCBNYXIgMjIsIDIwMDggYXQgNDo0MCBQTSwgSmVyZW15IENoYWR3aWNrIDxrb2l0c3VA ZnJlZWJzZC5vcmc+IHdyb3RlOgo+ICAkIGdjYyAtdgoKW3Rvb21hbnldIHJvb3RAfiMgZ2NjIC12 ClVzaW5nIGJ1aWx0LWluIHNwZWNzLgpUYXJnZXQ6IGkzODYtdW5kZXJteWRlc2stZnJlZWJzZApD b25maWd1cmVkIHdpdGg6IEZyZWVCU0QvaTM4NiBzeXN0ZW0gY29tcGlsZXIKVGhyZWFkIG1vZGVs OiBwb3NpeApnY2MgdmVyc2lvbiA0LjIuMSAyMDA3MDcxOSAgW0ZyZWVCU0RdCgo+ICAkIGVjaG8g J2ludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0nID4gdG1wLmMKPiAgJCBnY2MgLVdjaGFyLXN1 YnNjcmlwdHMgLW8geCB0bXAuYwoKSHVtbS4uLiBUaGlzIHdvcmtzIGZpbmUgaW4gdXNlciBtb2Rl Li4uIEJ1dCwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSwKaWYgSSBjb21tZW50ZWQgYWxsIGNjYWNo ZSBmbGFncyBpbiBtYWtlLmNvbmYgYW4gLmNzaHJjJ3Mgcm9vdCwgd2l0aCBvcgp3aXRob3V0IENG TEFHUywgaW4gbWFrZS5jb25mLCBldGMsIHRoZSBvdXRwdXQgKndhcyogdGhlIHNhbWU/Pz8KCj4g ICQgdW5hbWUgLW1ucnMKCkZyZWVCU0QgdG9vbWFueS50b29tYW55Lm5ldCA3LjAtUkVMRUFTRSBp Mzg2Cgo+ICAkIGVjaG8gJ2ludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0nID4gdG1wLmMKPiAg JCBnY2MgLVdjaGFyLXN1YnNjcmlwdHMgLW8geCB0bXAuYwoKVGhpcyB3b3JrcyBmaW5lIHVuZGVy IGEgbm9ybWFsIHVzZXIuIFVuZGVyIHJvb3QuLi4gYWxzbyEhIQoobm90ZSB0aGF0IEkgcmVhbGx5 IG1ha2UgYSBzdHJvbmcgdmVyaWZpY2F0aW9uIGFib3V0IGNjYWNoZSB1c2U7CmRlbGV0ZWQgZnJv bSBtYWtlLmNvbmYsIGRlbGV0ZWQgZnJvbSAuY3NocmMncyByb290IGFuZCBkZWxldGVkIHBvcnQK Y2NhY2hlKS4KCj4gIEl0IGNhbid0IGJlLiAgWW91J3JlIHJlZGVmaW5pbmcgQ0MgaW4gbWFrZS5j b25mLCBmb3IgZXhhbXBsZSwgc28gdGhpcwo+ICBvdXRwdXQgd291bGQgbm90IGJlIHRoZSBzYW1l Ogo+Cj4gIENDPScvdXNyL2xvY2FsL2xpYmV4ZWMvY2NhY2hlL3dvcmxkLWNjJyAgey4uLn0gIC91 c3IvbG9jYWwvbGliZXhlYy9jY2FjaGUvd29ybGQtY2Mgey4uLn0KPgo+ICBJIGRvbid0IG1lYW4g dG8gc291bmQgYW5hbCBhYm91dCBpdCwgYnV0IHRoZXJlJ3MgZGVmaW5pdGVseSBzb21ldGhpbmcK PiAgdW5pcXVlIHlvdXIgc3lzdGVtIHdoaWNoIGlzIGNhdXNpbmcgdGhpczsgY2hvb3NpbmcgYSBz ZXBhcmF0ZSBjb21waWxlcgo+ICBvciBjb21waWxlciB3cmFwcGVyIGlzIHRoZSBtb3N0IG9idmlv dXMgY2F1c2UuCgpPbmUgdGhpbmcgSSBkb24ndCBrbm93IGFib3V0IGl0LCBpcyB0aGUgImNjMSIu Li4gVGhlcmUgaXNuJ3QgYW55ICJjYzEiCmluIHRoZSBzeXN0ZW0sIGFuZCBhbHNvIGFueXRoaW5n IGFib3V0IGNjYWNoZSB3aXRoIGl0IChzb3JyeSBmb3IgbXkKYmFkIGVuZ2xpc2gpLgoKPiAgSSBz aG91bGQgbm90ZSB0aGF0IHVzZSBvZiA/PSB3b24ndCBmaXggeW91ciByZXBvcnRlZCBwcm9ibGVt IHdpdGgKPiAgLVdjaGFyLXN1YnNjcmlwdHMuICBJIHdhcyBqdXN0IHBvaW50aW5nIG91dCB0aGF0 IHlvdSBzaG91bGQgdXNlIGl0IHRvCj4gIGFsbG93IHByb2dyYW1zIHRvIG92ZXJyaWRlIHlvdXIg c2V0dGluZ3MgLS0gYmVjYXVzZSB0aGVyZSBhcmUgbWFueSBjYXNlcwo+ICB3aGVyZSBwcm9ncmFt cyB1c2Ugc3BlY2lmaWMgQ0ZMQUdTIHRvIGJ1aWxkIHRoaW5ncyBjb3JyZWN0bHkuCj4gIE92ZXJy aWRpbmcgdGhlbSBjYW4gYnJlYWsgdGhhdC4KCkknbSB0cnlpbmcgdG8gbWFrZSBhIGJ1aWxkd29y bGQgbm93LCBhbmQgYXQgdGhlIG1vbWVudC4uLiBCdXQgaGVyZSBpdAppczsgd2l0aG91dCBjY2Fj aGUgYW5kIG9ubHkgd2l0aCBzeXN0ZW0ncyBnY2M6CgpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNp bmcgLXBpcGUgLW1hcmNoPXByZXNjb3R0IC1ESU5fR0NDCi1ESEFWRV9MRF9FSF9GUkFNRV9IRFIg LUREVF9DT05GSUcgLURfX0dMSUJDX189MyAtZmluaGliaXQtc2l6ZS1kaXJlYwp0aXZlIC1mbm8t aW5saW5lLWZ1bmN0aW9ucyAgLWZuby1leGNlcHRpb25zCi1mbm8temVyby1pbml0aWFsaXplZC1p bi1ic3MgIC1mbm8temVyby1pbml0aWFsaXplZC1pbi1ic3MKLWZuby10b3BsZXZlbC1yZW9yZGVy IC1JLwp1c3Ivc3JjL2dudS9saWIvY3N1Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjbGlicy9pbmNsdWRl Ci1JL3Vzci9zcmMvZ251L2xpYi9jc3UvLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnCi1JL3Vz ci9zcmMvZ251L2xpYi9jc3UvLgouLy4uLy4uL2NvbnRyaWIvZ2NjIC1JLgotSS91c3Ivc3JjL2du dS9saWIvY3N1Ly4uLy4uL3Vzci5iaW4vY2MvY2NfdG9vbHMgLXN0ZD1nbnU4OSAgLWcwCi1EQ1JU X0JFR0lOIC1EQ1JUU1RVRkZUX08gIC1jIC1vIGNydGJlCmdpblQubyAvdXNyL3NyYy9nbnUvbGli L2NzdS8uLi8uLi8uLi9jb250cmliL2djYy9jcnRzdHVmZi5jCmNjIC1PMiAtZm5vLXN0cmljdC1h bGlhc2luZyAtcGlwZSAtbWFyY2g9cHJlc2NvdHQgLURJTl9HQ0MKLURIQVZFX0xEX0VIX0ZSQU1F X0hEUiAtRERUX0NPTkZJRyAtRF9fR0xJQkNfXz0zIC1maW5oaWJpdC1zaXplLWRpcmVjCnRpdmUg LWZuby1pbmxpbmUtZnVuY3Rpb25zICAtZm5vLWV4Y2VwdGlvbnMKLWZuby16ZXJvLWluaXRpYWxp emVkLWluLWJzcyAgLWZuby16ZXJvLWluaXRpYWxpemVkLWluLWJzcwotZm5vLXRvcGxldmVsLXJl b3JkZXIgLUkvCnVzci9zcmMvZ251L2xpYi9jc3UvLi4vLi4vLi4vY29udHJpYi9nY2NsaWJzL2lu Y2x1ZGUKLUkvdXNyL3NyYy9nbnUvbGliL2NzdS8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcK LUkvdXNyL3NyYy9nbnUvbGliL2NzdS8uCi4vLi4vLi4vY29udHJpYi9nY2MgLUkuCi1JL3Vzci9z cmMvZ251L2xpYi9jc3UvLi4vLi4vdXNyLmJpbi9jYy9jY190b29scyAtc3RkPWdudTg5ICAtZzAK LURDUlRfQkVHSU4gLURDUlRTVFVGRlNfTyAtRFNIQVJFRCAtZnAKaWMgIC1jIC1vIGNydGJlZ2lu LlNvIC91c3Ivc3JjL2dudS9saWIvY3N1Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NydHN0dWZmLmMK Y2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1tYXJjaD1wcmVzY290dCAtRElOX0dD QwotREhBVkVfTERfRUhfRlJBTUVfSERSIC1ERFRfQ09ORklHIC1EX19HTElCQ19fPTMgLWZpbmhp Yml0LXNpemUtZGlyZWMKdGl2ZSAtZm5vLWlubGluZS1mdW5jdGlvbnMgIC1mbm8tZXhjZXB0aW9u cwotZm5vLXplcm8taW5pdGlhbGl6ZWQtaW4tYnNzICAtZm5vLXplcm8taW5pdGlhbGl6ZWQtaW4t YnNzCi1mbm8tdG9wbGV2ZWwtcmVvcmRlciAtSS8KdXNyL3NyYy9nbnUvbGliL2NzdS8uLi8uLi8u Li9jb250cmliL2djY2xpYnMvaW5jbHVkZQotSS91c3Ivc3JjL2dudS9saWIvY3N1Ly4uLy4uLy4u L2NvbnRyaWIvZ2NjL2NvbmZpZwotSS91c3Ivc3JjL2dudS9saWIvY3N1Ly4KLi8uLi8uLi9jb250 cmliL2djYyAtSS4KLUkvdXNyL3NyYy9nbnUvbGliL2NzdS8uLi8uLi91c3IuYmluL2NjL2NjX3Rv b2xzIC1zdGQ9Z251ODkgIC1nMAotRENSVF9FTkQgLURDUlRTVFVGRlNfTyAtRFNIQVJFRCAtZnBp YwogIC1jIC1vIGNydGVuZC5TbyAvdXNyL3NyYy9nbnUvbGliL2NzdS8uLi8uLi8uLi9jb250cmli L2djYy9jcnRzdHVmZi5jCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3 aGVlbCAtbSA0NDQgIGNydGJlZ2luLm8KL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2xpYi9jcnRi ZWdpbi5vCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0 NDQgIGNydGVuZC5vCi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9saWIvY3J0ZW5kLm8Kc2ggL3Vz ci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgY3J0YmVnaW5U Lm8KL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2xpYi9jcnRiZWdpblQubwpzaCAvdXNyL3NyYy90 b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBjcnRiZWdpbi5TbwovdXNy L29iai91c3Ivc3JjL3RtcC91c3IvbGliL2NydGJlZ2luUy5vCnNoIC91c3Ivc3JjL3Rvb2xzL2lu c3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGNydGVuZC5TbwovdXNyL29iai91c3Iv c3JjL3RtcC91c3IvbGliL2NydGVuZFMubwo9PT0+IGxpYi9jc3UvaTM4Ni1lbGYgKG9iaixkZXBl bmQsYWxsLGluc3RhbGwpCnJtIC1mIC5kZXBlbmQKbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS91 c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYvLi4vY29tbW9uCi1JL3Vzci9zcmMvbGliL2NzdS9pMzg2 LWVsZi8uLi8uLi9saWJjL2luY2x1ZGUgL3Vzci9zcmMvbGliL2NzdS9pMzgKNi1lbGYvY3J0MS5j IC91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYvY3J0aS5TIC91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1l bGYvY3J0bi5TCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtbWFyY2g9cHJlc2Nv dHQKLUkvdXNyL3NyYy9saWIvY3N1L2kzODYtZWxmLy4uL2NvbW1vbgotSS91c3Ivc3JjL2xpYi9j c3UvaTM4Ni1lbGYvLi4vLi4vbGliYy8KaW5jbHVkZSAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1X bm8tZm9ybWF0LXkyayAtVwotV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBl cyAtV21pc3NpbmctcHJvdG90eXBlcwotV3BvaW50ZXItYXJpdGgKIC1XcmV0dXJuLXR5cGUgLVdj YXN0LXF1YWwgLVd3cml0ZS1zdHJpbmdzIC1Xc3dpdGNoIC1Xc2hhZG93Ci1XY2FzdC1hbGlnbiAt V3VudXNlZC1wYXJhbWV0ZXIgLVdjaGFyLXN1YnNjcmlwdHMgLVdpbmxpbmUgLVduZXN0ZWQKLWV4 dGVybnMgLVdyZWR1bmRhbnQtZGVjbHMgLVduby1wb2ludGVyLXNpZ24gLWMgL3Vzci9zcmMvbGli L2NzdS9pMzg2LWVsZi9jcnQxLmMKY2MxOiBlcnJvcjogdW5yZWNvZ25pemVkIGNvbW1hbmQgbGlu ZSBvcHRpb24gIi1XY2hhci1zdWJzY3JpcHRzIgoqKiogRXJyb3IgY29kZSAxCgpTdG9wIGluIC91 c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYuCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9z cmMuCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMuCioqKiBFcnJvciBjb2RlIDEK ClN0b3AgaW4gL3Vzci9zcmMuCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMKClRo aXMgaXMgd2l0aG91dCBjY2FjaGUgYW5kIHdpdGggQ0ZMQUdTLi4uIDotLwpSZWFsbHkuLi4gSSBk b24ndCBrbm93IHdoYXQgdG8gZG8uLi4gOi0oCgpUaGFuayB5b3UgSmVyZW15LgoKLS0gCkhhdmUg YSBuaWNlIGRheSA7LSkKVG9vTWFueVNlY3JldHMKCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KRGlqbyBDb25mdWNpbzoKIkV4w61nZXRlIG11Y2hvIGEgdGkgbWlzbW8geSBlc3BlcmEgcG9j byBkZSBsb3MgZGVtw6FzLiBBc8OtIHRlIGFob3JyYXLDoXMKZGlzZ3VzdG9zLiIKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PQo= From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 17:20:37 2008 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 3DF58106564A for ; Sat, 22 Mar 2008 17:20:37 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 335E58FC15 for ; Sat, 22 Mar 2008 17:20:37 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 167AF1CC068; Sat, 22 Mar 2008 10:20:37 -0700 (PDT) Date: Sat, 22 Mar 2008 10:20:37 -0700 From: Jeremy Chadwick To: TooMany Secrets Message-ID: <20080322172037.GA35505@eos.sc1.parodius.com> References: <20080322144243.GB31702@eos.sc1.parodius.com> <20080322154039.GA33018@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 17:20:37 -0000 On Sat, Mar 22, 2008 at 05:08:57PM +0100, TooMany Secrets wrote: > > $ echo 'int main(void) { return 0; }' > tmp.c > > $ gcc -Wchar-subscripts -o x tmp.c > > This works fine under a normal user. Under root... also!!! > (note that I really make a strong verification about ccache use; > deleted from make.conf, deleted from .cshrc's root and deleted port > ccache). Then it's something that's happening in the buildworld framework. You might have some weirder stuff in /etc/make.conf, or /etc/src.conf. The src.conf stuff would affect your buildworld capabilities. > One thing I don't know about it, is the "cc1"... There isn't any "cc1" > in the system, and also anything about ccache with it (sorry for my > bad english). If I remember correctly, cc1 is the name of the temporary compiler (it's gcc) built in /usr/obj. buildworld builds gcc, and uses that copy of gcc to compile world, rather than /usr/bin/gcc. > I'm trying to make a buildworld now, and at the moment... But here it > is; without ccache and only with system's gcc: > > ===> lib/csu/i386-elf (obj,depend,all,install) > rm -f .depend > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i38 > 6-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > cc -O2 -fno-strict-aliasing -pipe -march=prescott > -I/usr/src/lib/csu/i386-elf/../common > -I/usr/src/lib/csu/i386-elf/../../libc/ > include -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested > -externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c > cc1: error: unrecognized command line option "-Wchar-subscripts" I can't explain what's going on here. I don't have this problem. FWIW, there's some historic reports of this kind of issue, with different issues. Some are due to users dotfiles, others are due to mixed gcc versions on the system (users trying to use gcc 3.4 with gcc 4.x flags like -Wno-pointer-sign), and others are due to CFLAGS modifications. http://groups.google.com/group/comp.unix.bsd.freebsd.misc/browse_thread/thread/a0af29b813232cd1/a1082e5d4200d10a?hl=en&lnk=st&q=gcc+unrecognized+command+line+option+freebsd#a1082e5d4200d10a http://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/15e5e69b5a93413a/ca03b7c3e08c01a2?hl=en&lnk=st&q=gcc+unrecognized+command+line+option#ca03b7c3e08c01a2 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 17:58:23 2008 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 2A40D1065670 for ; Sat, 22 Mar 2008 17:58:23 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE3D8FC1C for ; Sat, 22 Mar 2008 17:58:22 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so2265899waf.3 for ; Sat, 22 Mar 2008 10:58:22 -0700 (PDT) Received: by 10.115.73.20 with SMTP id a20mr8434327wal.32.1206208702307; Sat, 22 Mar 2008 10:58:22 -0700 (PDT) Received: by 10.114.27.6 with HTTP; Sat, 22 Mar 2008 10:58:22 -0700 (PDT) Message-ID: Date: Sat, 22 Mar 2008 18:58:22 +0100 From: "TooMany Secrets" To: "Jeremy Chadwick" In-Reply-To: <20080322172037.GA35505@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080322144243.GB31702@eos.sc1.parodius.com> <20080322154039.GA33018@eos.sc1.parodius.com> <20080322172037.GA35505@eos.sc1.parodius.com> Cc: freebsd-stable Subject: Re: Error compiling buildworld 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, 22 Mar 2008 17:58:23 -0000 T24gU2F0LCBNYXIgMjIsIDIwMDggYXQgNjoyMCBQTSwgSmVyZW15IENoYWR3aWNrIDxrb2l0c3VA ZnJlZWJzZC5vcmc+IHdyb3RlOgo+ICBGV0lXLCB0aGVyZSdzIHNvbWUgaGlzdG9yaWMgcmVwb3J0 cyBvZiB0aGlzIGtpbmQgb2YgaXNzdWUsIHdpdGgKPiAgZGlmZmVyZW50IGlzc3Vlcy4gIFNvbWUg YXJlIGR1ZSB0byB1c2VycyBkb3RmaWxlcywgb3RoZXJzIGFyZSBkdWUgdG8KPiAgbWl4ZWQgZ2Nj IHZlcnNpb25zIG9uIHRoZSBzeXN0ZW0gKHVzZXJzIHRyeWluZyB0byB1c2UgZ2NjIDMuNCB3aXRo IGdjYwo+ICA0LnggZmxhZ3MgbGlrZSAtV25vLXBvaW50ZXItc2lnbiksIGFuZCBvdGhlcnMgYXJl IGR1ZSB0byBDRkxBR1MKPiAgbW9kaWZpY2F0aW9ucy4KPgo+ICBodHRwOi8vZ3JvdXBzLmdvb2ds ZS5jb20vZ3JvdXAvY29tcC51bml4LmJzZC5mcmVlYnNkLm1pc2MvYnJvd3NlX3RocmVhZC90aHJl YWQvYTBhZjI5YjgxMzIzMmNkMS9hMTA4MmU1ZDQyMDBkMTBhP2hsPWVuJmxuaz1zdCZxPWdjYyt1 bnJlY29nbml6ZWQrY29tbWFuZCtsaW5lK29wdGlvbitmcmVlYnNkI2ExMDgyZTVkNDIwMGQxMGEK Pgo+ICBodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvbWFpbGluZy5mcmVlYnNkLnBvcnRz L2Jyb3dzZV90aHJlYWQvdGhyZWFkLzE1ZTVlNjliNWE5MzQxM2EvY2EwM2I3YzNlMDhjMDFhMj9o bD1lbiZsbms9c3QmcT1nY2MrdW5yZWNvZ25pemVkK2NvbW1hbmQrbGluZStvcHRpb24jY2EwM2I3 YzNlMDhjMDFhMgoKVGhhbmsgeW91IEplcmVteSwgSSdtIHRyeWluZyBub3cgd2l0aCBNQUtFX1NI RUxMPz1zaCBpbnRvCi9ldGMvbWFrZS5jb25mLCBhbmQgYWxzbywgbWFrZSBhICJzdWRvIHN1IiAo d2lodG91dCAiLSIpIGZyb20gbm9ybWFsCnVzZXIsIGluc3RlYWQgdXNpbmcgYSBub3JtYWwgbG9n aW4gZnJvbSByb290LgpUaGUgLmNzaHJjIGluIHJvb3QgJEhPTUUgaXMgdGhlIHNhbWUgaSdtIHVz aW5nIGludG8gc29tZSBzZXJ2ZXJzIGF0CndvcmsuLi4gUmVhbGx5LCBpcyB0aGUgZmlyc3QgdGlt ZSBJIGhhdmUgdGhpcyB0eXBlIG9mIHByb2JsZW1zLi4uCgpSZWdhcmRzLgoKLS0gCkhhdmUgYSBu aWNlIGRheSAgOy0pClRvb01hbnlTZWNyZXRzCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 CkRpam8gQ29uZnVjaW86CiJFeMOtZ2V0ZSBtdWNobyBhIHRpIG1pc21vIHkgZXNwZXJhIHBvY28g ZGUgbG9zIGRlbcOhcy4gQXPDrSB0ZSBhaG9ycmFyw6FzCmRpc2d1c3Rvcy4iCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT0K From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 18:34:26 2008 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 43EBC106566B for ; Sat, 22 Mar 2008 18:34:26 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.freebsd.org (Postfix) with ESMTP id 11F228FC14 for ; Sat, 22 Mar 2008 18:34:25 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from localhost (80.221.11.59) by pne-smtpout3-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A788570028743C for freebsd-stable@freebsd.org; Sat, 22 Mar 2008 18:25:07 +0100 Date: Sat, 22 Mar 2008 19:24:33 +0200 From: Mikael Ikivesi To: freebsd-stable@freebsd.org Message-ID: <20080322192433.3719eb44@pp.inet.fi> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: gcc -O2 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: Sat, 22 Mar 2008 18:34:26 -0000 Hi I am running uptodate RELENG_7. It has gcc (GCC) 4.2.1 20070719 [FreeBSD]. I tried to track down segfaults from my code and I accidentaly found a optimization error. Code did not segfault when compiled without optimization but crashed when -O2 was used. I tried to track it I could make the gcc give me following error by simply stripping few lines: ----------------------- wrong.c: In function 'wrong': wrong.c:11: error: Attempt to delete prologue/epilogue insn: (insn/f 47 46 48 2 (set (mem:SI (plus:SI (reg/f:SI 6 bp) (const_int -8 [0xfffffffffffffff8])) [0 S4 A8]) (reg:SI 3 bx)) -1 (nil) (nil)) wrong.c:11: internal compiler error: in propagate_one_insn, at flow.c:1735 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ------------------ And this is what triggers it: #include #include #define max_word_len 64 wchar_t *wrong(wchar_t *wordlist, wchar_t *word) { wchar_t buffer[max_word_len+2]; buffer[max_word_len+2]=0; if(wcsstr(wordlist,buffer)==0) wcscpy(wordlist,buffer); return wordlist; } -Mikael From owner-freebsd-stable@FreeBSD.ORG Sat Mar 22 18:39:27 2008 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 8BAA21065672 for ; Sat, 22 Mar 2008 18:39:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CF4CB8FC18; Sat, 22 Mar 2008 18:39:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E55264.2030004@FreeBSD.org> Date: Sat, 22 Mar 2008 19:39:32 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Mikael Ikivesi References: <20080322192433.3719eb44@pp.inet.fi> In-Reply-To: <20080322192433.3719eb44@pp.inet.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: gcc -O2 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: Sat, 22 Mar 2008 18:39:27 -0000 Mikael Ikivesi wrote: > Hi > > I am running uptodate RELENG_7. It has gcc (GCC) 4.2.1 20070719 > [FreeBSD]. > > I tried to track down segfaults from my code and I accidentaly found a > optimization error. Code did not segfault when compiled without > optimization but crashed when -O2 was used. > > I tried to track it I could make the gcc give me following error by > simply stripping few lines: > > ----------------------- > wrong.c: In function 'wrong': > wrong.c:11: error: Attempt to delete prologue/epilogue insn: > (insn/f 47 46 48 2 (set (mem:SI (plus:SI (reg/f:SI 6 bp) > (const_int -8 [0xfffffffffffffff8])) [0 S4 A8]) > (reg:SI 3 bx)) -1 (nil) > (nil)) > wrong.c:11: internal compiler error: in propagate_one_insn, at > flow.c:1735 Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. So, did you consider perhaps following this advice? ;-) Kris