From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 06:48:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E99AA16A4CE; Sun, 17 Apr 2005 06:48:22 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D99543D45; Sun, 17 Apr 2005 06:48:22 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3H6mA7H041614; Sun, 17 Apr 2005 02:48:10 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3H6m2vr041602; Sun, 17 Apr 2005 02:48:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 17 Apr 2005 02:48:02 -0400 (EDT) From: Andre Guibert de Bruet To: Julian Elischer In-Reply-To: <42617BA9.8070101@elischer.org> Message-ID: <20050417024042.L93987@lexi.siliconlandmark.com> References: <425CC7F8.3030803@samsco.org> <425CD009.6040208@freebsd.org> <20050413132603.GA39006@orion.daedalusnetworks.priv> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <425FA2AB.4070905@freebsd.org><425FFCF1.1080100@elischer.org> <4260D92C.1030703@freebsd.org> <42617BA9.8070101@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.522, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org cc: Giorgos Keramidas cc: David Xu cc: Jiawei Ye cc: Anthony Ginepro Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 06:48:23 -0000 On Sat, 16 Apr 2005, Julian Elischer wrote: > David Xu wrote: >> Andre Guibert de Bruet wrote: >>> On Fri, 15 Apr 2005, Julian Elischer wrote: >>>> Giorgos Keramidas wrote: >>>>> On 2005-04-15 19:16, David Xu wrote: >>>>> >>>>> I just checked what top does on SunOS, when a program has more than 999 >>>>> threads and it seems to clip the number of threads to 999, as if >>>>> something min(999, numthreads) is what is printed :-) >>>> >>>> you could proint " !!!" or "LOT" >>>> or do a roman numeral approx. >>>> e.g. MMC (2100).. what's roman for 10000? >>>> or 2E4 :-) >>> >>> I realize that top isn't an exact science, but I find that approximations >>> are generally a bad idea. I am in favor of axing the useless CPU column >>> and reclaiming some useful screen space for the others... :) >> >> CPU column is not very useful when displaying process and >> thread count, if it is only useful if it is displaying individual >> thread which is activated by 'H' key. > > CPU and thread count column could be shared > > [CPU] )[1] [2] [3] ...[99] could be CPUnum.. > that implies 1 thread > 2..9999 is a thread count > > when H mode is on, then we just show [CPUNUM] > wnen not we show [CPUNUM] or threadcount. I would like to make sure that we're all talking about the same CPU column here. I was referering to the one that is immediately to the left of the COMMAND field (To the right of WCPU) and not the "C" column which displays the proc on which the thread/process is running on. Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 06:51:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F3316A4CE; Sun, 17 Apr 2005 06:51:27 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0277543D58; Sun, 17 Apr 2005 06:51:27 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3H6pOl4046564; Sun, 17 Apr 2005 02:51:24 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3H6pOOS046561; Sun, 17 Apr 2005 02:51:24 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 17 Apr 2005 02:51:24 -0400 (EDT) From: Andre Guibert de Bruet To: Giorgos Keramidas In-Reply-To: <20050416154412.GA7299@gothmog.gr> Message-ID: <20050417024815.Y93987@lexi.siliconlandmark.com> References: <425CC7F8.3030803@samsco.org> <425D2163.4090603@freebsd.org> <20050413141957.GA40546@orion.daedalusnetworks.priv> <20050415055604.N93987@lexi.siliconlandmark.com> <20050416154412.GA7299@gothmog.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.523, required 6, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: How does one know how many thread a process owns? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 06:51:27 -0000 On Sat, 16 Apr 2005, Giorgos Keramidas wrote: > On 2005-04-15 13:48, Giorgos Keramidas wrote: >> On 2005-04-15 06:02, Andre Guibert de Bruet wrote: >>> Please commit the following patch which unbreaks the display problems >>> which appear on 80-column terminals with the THR column (The D would wrap >>> and cause weird behavior): >>> >>> http://bling.properkernel.com/freebsd/top.machine.c.patch >> >> This seems reasonable. I only have UP machines, which don't need the change >> from COMMAND to CMD, but Andrey Chernov has already brought to my attention >> that adding the THR column broke the listing in SMP machines. > > Should be fixed now. I shortened THR to 4 columns. Thank you sir! Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 07:00:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C0C116A4CE; Sun, 17 Apr 2005 07:00:15 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BD343D53; Sun, 17 Apr 2005 07:00:14 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3H70BYc030987; Sun, 17 Apr 2005 03:00:11 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3H707uJ030952; Sun, 17 Apr 2005 03:00:11 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 17 Apr 2005 03:00:07 -0400 (EDT) From: Andre Guibert de Bruet To: "Daniel O'Connor" In-Reply-To: <200504161349.39693.doconnor@gsoft.com.au> Message-ID: <20050417025742.H93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> <20050415213404.E93987@lexi.siliconlandmark.com> <200504161349.39693.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.524, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: alc@freebsd.org cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 07:00:15 -0000 On Sat, 16 Apr 2005, Daniel O'Connor wrote: > On Sat, 16 Apr 2005 11:18, Andre Guibert de Bruet wrote: >> I am currently 40 miles (64 km) away from this system so it is sort of >> hard to switch VTs. I do have ssh access to the machine and the corefile >> that I obtained. I can spend some time this weekend trying to figure out a >> SoE for this... Wish me luck! > > Does vidcontrol -s X cause the problem? Locally, it works just fine. At the serial console, it yields the "Inapproriate ioctl for device" message that one would expect. Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 07:00:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C0C116A4CE; Sun, 17 Apr 2005 07:00:15 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BD343D53; Sun, 17 Apr 2005 07:00:14 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3H70BYc030987; Sun, 17 Apr 2005 03:00:11 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3H707uJ030952; Sun, 17 Apr 2005 03:00:11 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 17 Apr 2005 03:00:07 -0400 (EDT) From: Andre Guibert de Bruet To: "Daniel O'Connor" In-Reply-To: <200504161349.39693.doconnor@gsoft.com.au> Message-ID: <20050417025742.H93987@lexi.siliconlandmark.com> References: <20050415063120.G93987@lexi.siliconlandmark.com> <20050415213404.E93987@lexi.siliconlandmark.com> <200504161349.39693.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.524, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: alc@freebsd.org cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: syscons joy: reproduceable panic on resolution change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 07:00:15 -0000 On Sat, 16 Apr 2005, Daniel O'Connor wrote: > On Sat, 16 Apr 2005 11:18, Andre Guibert de Bruet wrote: >> I am currently 40 miles (64 km) away from this system so it is sort of >> hard to switch VTs. I do have ssh access to the machine and the corefile >> that I obtained. I can spend some time this weekend trying to figure out a >> SoE for this... Wish me luck! > > Does vidcontrol -s X cause the problem? Locally, it works just fine. At the serial console, it yields the "Inapproriate ioctl for device" message that one would expect. Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 18:54:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9586016A4CE for ; Sat, 16 Apr 2005 18:54:05 +0000 (GMT) Received: from home.berger.to (client80-83-46-98.abo.net2000.ch [80.83.46.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED46C43D3F for ; Sat, 16 Apr 2005 18:53:59 +0000 (GMT) (envelope-from cedric@berger.to) Received: from [192.168.2.65] ([192.168.2.65]) by home.berger.to (8.13.0/8.12.11) with ESMTP id j3GIrWIX000703; Sat, 16 Apr 2005 20:53:32 +0200 (CEST) Message-ID: <42615F06.6090505@berger.to> Date: Sat, 16 Apr 2005 20:52:54 +0200 From: Cedric Berger User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <4261185D.1060202@gamersimpact.com> <13591.1113660644@bizet.nethelp.no> <20050416165000.GA69374@regency.nsu.ru> <20050416171726.GA27283@freebie.xs4all.nl> In-Reply-To: <20050416171726.GA27283@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 17 Apr 2005 12:02:51 +0000 cc: ryans@gamersimpact.com cc: Alexey Dokuchaev cc: tech@openbsd.org cc: sthaug@nethelp.no cc: freebsd-current@freebsd.org Subject: Re: strtonum(3) in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 18:54:05 -0000 >Whether you like it or not, this is pretty much the industry standard >in the storage industry. Not much option but to get used to it.. > > Since it appear ppl love useless flames, I'm suggesting expanding that storage and unit discussion in two new topics: 1) Why US units (inches, feets) sucks and ISO units are great. 2) Given Einstein insight, Will the access time of hard drive increase if they move close to the speed of light? From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:24:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BB3116A4CE for ; Sat, 16 Apr 2005 19:24:36 +0000 (GMT) Received: from ns01.connect.az (ns02.connect.az [62.212.236.162]) by mx1.FreeBSD.org (Postfix) with SMTP id 9260E43D49 for ; Sat, 16 Apr 2005 19:24:34 +0000 (GMT) (envelope-from tofik@oxygen.az) Received: (qmail 36549 invoked from network); 16 Apr 2005 22:25:03 -0000 Received: from unknown (HELO ?192.168.0.101?) (192.168.0.101) by office.connect.az with SMTP; 16 Apr 2005 22:25:03 -0000 Message-ID: <42617480.5080903@oxygen.az> Date: Sun, 17 Apr 2005 01:24:32 +0500 From: Tofik Suleymanov User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey References: <20050416154321.42E1243D58@mx1.FreeBSD.org> In-Reply-To: <20050416154321.42E1243D58@mx1.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 17 Apr 2005 12:02:51 +0000 cc: freebsd-current@freebsd.org Subject: Re: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 19:24:36 -0000 Jeffrey wrote: >Does anyone know more about support for the promise fasttrak tx 4200? It >isn't in the current. > > > > We've got fasttrack tx2200 (the same chipset as 4400) and it not recognized at all on 5.3-RELEASE. I am also interested in any information about support of this hardware on RELENG_5. From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 12:30:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B2B16A4CE; Sun, 17 Apr 2005 12:30:57 +0000 (GMT) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C26643D2F; Sun, 17 Apr 2005 12:30:57 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.50 (FreeBSD)) id 1DN8gv-0000HZ-HO; Sun, 17 Apr 2005 16:15:57 +0400 From: Vladimir Grebenschikov To: mobile@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Sun, 17 Apr 2005 16:15:56 +0400 Message-Id: <1113740156.1018.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: devd + driver load by plugged device class how to ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 12:30:58 -0000 Hi Is there way to configure devd (or other daemon) to load appropriate driver by class, when device detected on bus, like: load ukbd.ko when USB keyboard plugged (same for other USB ums, ulpt, umass, etc) load atacard.ko, when ATA disk inserted into PCMCI slot load if_wi.ko when WLan card inserted into PCMCI slot and so on ... -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 13:26:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E7B016A4CE for ; Sun, 17 Apr 2005 13:26:01 +0000 (GMT) Received: from md.gfk.ru (md.f231.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id F15EB43D31 for ; Sun, 17 Apr 2005 13:25:59 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by gfk.ru (md.gfk.ru [62.205.179.201]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 52-md50000000495.tmp for ; Sun, 17 Apr 2005 17:25:17 +0400 Date: Sun, 17 Apr 2005 17:25:16 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: current@freebsd.org Message-ID: <20050417162152.H508@free.home.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Processed: md.gfk.ru, Sun, 17 Apr 2005 17:25:17 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.6.45 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: current@freebsd.org cc: Yuriy.Tsibizov@gfk.ru Subject: if_ndis: kernel trap 9 with interrupts disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 13:26:01 -0000 On -CURRENT from Saturday, D-Link DWL-G650+ (TNET1130 chipset) NDIS driver for Windows 2000 dated 04/09/2004 version 6.0.0.18. ndis.ko: $FreeBSD: src/sys/compat/ndis/subr_pe.c,v 1.11 2005/02/24 17:58:27 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/subr_ndis.c,v 1.84 2005/04/11 02:02:34 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/subr_hal.c,v 1.20 2005/04/11 02:02:34 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/subr_ntoskrnl.c,v 1.64 2005/04/11 02:02:34 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/kern_ndis.c,v 1.77 2005/04/11 02:02:34 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/kern_windrv.c,v 1.6 2005/04/11 02:02:34 wpaul Exp $ $FreeBSD: src/sys/compat/ndis/subr_usbd.c,v 1.2 2005/04/11 02:02:34 wpaul Exp $ if_ndis.ko: $FreeBSD: src/sys/dev/if_ndis/if_ndis.c,v 1.86 2005/04/11 02:02:35 wpaul Exp $ $FreeBSD: src/sys/dev/if_ndis/if_ndis_pci.c,v 1.14 2005/03/27 10:35:07 wpaul Exp $ $FreeBSD: src/sys/dev/if_ndis/if_ndis_pccard.c,v 1.10 2005/02/28 16:47:54 wpaul Exp $ dmesg: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #0: Sun Apr 17 14:06:22 MSD 2005 chibis@free.home.local:/usr/obj/usr/src/sys/FREE-FAST WARNING: WITNESS option enabled, expect reduced performance. WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x80000800 real memory = 268435456 (256 MB) avail memory = 253386752 (241 MB) K6-family MTRR support enabled (2 registers) ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 [...] pci0: at device 10.0 (no driver attached) [...] (kldload if_ndis) ndis0: mem 0xe6000000-0xe6001fff,0xe5800000-0xe581ffff irq 9 at device 10.0 on pci0 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.0 kernel trap 9 with interrupts disabled [...] kernel trap 9 with interrupts disabled ndis0: Ethernet address: 00:0f:3d:59:49:38 kernel trap 9 with interrupts disabled kernel trap 9 with interrupts disabled kernel trap 9 with interrupts disabled pid 386 (sendmail), uid 0: exited on signal 10 kernel trap 9 with interrupts disabled kernel trap 9 with interrupts disabled Yuriy Tsibizov From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 14:00:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7947116A4F4; Sun, 17 Apr 2005 14:00:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6E943D31; Sun, 17 Apr 2005 14:00:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3HE2rPZ069113; Sun, 17 Apr 2005 08:02:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42626B36.1090204@samsco.org> Date: Sun, 17 Apr 2005 07:57:10 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org References: <200504080220.57899.max@love2party.net> In-Reply-To: <200504080220.57899.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: monthly@freebsd.org Subject: REMINDER! Call for FreeBSD status reports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 14:00:28 -0000 All, This is a reminder that status reports are due. We are going to extend the deadline until the 20th to encourage people to submit a few more reports. If you have any projects that you've been working on in the past 3 months that are interesting and you would like to share, please submit a report as soon as possible. The new web form from Julian makes it incredibly easy to generate a submission without having to know a thing about XML. The link for this is at: http://www.freebsd.org/cgi/monthly.cgi So, please submit your reports to monthly@freebsd.org by the 20th. Thanks, Scott Long, Max Laier, Tom Rhodes Max Laier wrote: > All, > > It's time again for some recapitulation of your FreeBSD activities of the last > months. In order to not collided with the preparation of the 5.4 release we > extended the cycle from bi-monthly to three months, so this one is open for > anything that happend in 2005 until now. Submissions are due by April 15 to > monthly@freebsd.org > > As always, reports about every FreeBSD related activity of the past months and > coming weeks are welcome. In the past there was some focus on technical > issues. In order to turn this into a more complete PR-vehicle, we highly > encourage and welcome reports on non-technical matters as well. > > If you are yet unfamiliar with the status-reports, please take a look at the > past reports: http://www.FreeBSD.org/news/status/ > > To support you in the process of fitting your report into the xml-template > (available from: http://www.freebsd.org/news/status/report-sample.xml for > those who still prefer a plain old text editor) Julian Elischer came up with > the idea and prototype to have a web based form. Many thanks for that work. > The cgi-script is being reviewed on freebsd-www now and will be linked to > from http://www.freebsd.org/news/status/ shortly. > > The new features from last time (categories and task-list) will be available, > again. As a reminder the available categories are listed bellow. Please > feel free to suggest additional entries: > > proj - Projects (non-specific) > docs - Documentation > kern - Kernel > arch - Architectures > ports - Ports > vendor - Vendor / 3rd party software > misc - Miscellaneous > > Submissions are due on April 15. Thanks a lot, and we are hoping for a big > turn-out. > From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 17:11:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB68D16A4CE; Sun, 17 Apr 2005 17:11:22 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7898743D5A; Sun, 17 Apr 2005 17:11:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3HHA9p6044129; Sun, 17 Apr 2005 11:10:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Apr 2005 11:10:15 -0600 (MDT) Message-Id: <20050417.111015.77928634.imp@bsdimp.com> To: vova@fbsd.ru From: "M. Warner Losh" In-Reply-To: <1113740156.1018.6.camel@localhost> References: <1113740156.1018.6.camel@localhost> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mobile@freebsd.org cc: current@freebsd.org Subject: Re: devd + driver load by plugged device class how to ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 17:11:23 -0000 In message: <1113740156.1018.6.camel@localhost> Vladimir Grebenschikov writes: : Is there way to configure devd (or other daemon) to load appropriate : driver by class, when device detected on bus, like: Yes. That's what nomatch events are for. The default devd.conf momatch entries in it. : load ukbd.ko when USB keyboard plugged (same for other USB ums, ulpt, : umass, etc) usb doesn't support reprobing correctly yet, so this isn't possible until it does. : load atacard.ko, when ATA disk inserted into PCMCI slot nomatch 10 { match "bus" "pccard[0-9]+]; match "function_type" "4"; action "kldload atacard"; } : load if_wi.ko when WLan card inserted into PCMCI slot This device supports a large number of devices, so the list is rather long... Warner From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 17:52:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A94716A4CE for ; Sun, 17 Apr 2005 17:52:27 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFFB643D3F for ; Sun, 17 Apr 2005 17:52:26 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 6260 invoked from network); 17 Apr 2005 17:52:26 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Apr 2005 17:52:26 -0000 Received: from hydrogen.funkthat.com (lghcxi@localhost.funkthat.com [127.0.0.1])j3HHqPD2052392; Sun, 17 Apr 2005 10:52:25 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j3HHqPU2052391; Sun, 17 Apr 2005 10:52:25 -0700 (PDT) Date: Sun, 17 Apr 2005 10:52:25 -0700 From: John-Mark Gurney To: Ivan Voras Message-ID: <20050417175225.GC16099@funkthat.com> Mail-Followup-To: Ivan Voras , Poul-Henning Kamp , current@freebsd.org References: <42616975.9060303@centtech.com> <3703.1113680811@critter.freebsd.dk> <4261996A.2030204@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4261996A.2030204@fer.hr> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 17:52:27 -0000 Ivan Voras wrote this message on Sun, Apr 17, 2005 at 01:02 +0200: > Poul-Henning Kamp wrote: > > >The reason gstat shows >100% busy is that there are some outstanding > >requests. (the 2 in the left hand column). > > > >I tried to make the statistics collection as cheap as possible, and > >as a side effect some of the columns can be somewhat misleading. > > Could it be (for reasons of prettyfication) clipped to [0-100] range? > Something like in the attached? It could, but IMO, leaving them unclipped will continue to show that the numbers are complete apporimations and not to be depended upon.. If they were to always show 0-100%, people might start putting more meaning into them than is really there (as phk enumerated in a previous message)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 18:10:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B80916A4D0 for ; Sun, 17 Apr 2005 18:10:46 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADFD043D4C for ; Sun, 17 Apr 2005 18:10:45 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so1327125nzf for ; Sun, 17 Apr 2005 11:10:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=asUhfGK+uuYHoO+RrbkMaTYA2OYOaWnvUMDRPUzdcJwWk/nbrz28DaG9n5AP3Pkoacmtlgq4w5ixQ6Ma/L0P81ytXJ43cubNSkWmGYLg4wZ94+uVd093lMp/95MYUZVHjI8+kprBbAW7m0pfHJtcqllVx253L6igs1LRI4gvBms= Received: by 10.36.67.3 with SMTP id p3mr308953nza; Sun, 17 Apr 2005 11:10:44 -0700 (PDT) Received: by 10.36.68.4 with HTTP; Sun, 17 Apr 2005 11:10:44 -0700 (PDT) Message-ID: <34cb7c840504171110737bba62@mail.gmail.com> Date: Sun, 17 Apr 2005 19:10:44 +0100 From: Peter Edwards To: Yuriy Tsibizov In-Reply-To: <20050417162152.H508@free.home.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_17616_4427029.1113761444939" References: <20050417162152.H508@free.home.local> cc: wpaul@freebsd.org cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: if_ndis: kernel trap 9 with interrupts disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 18:10:46 -0000 ------=_Part_17616_4427029.1113761444939 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 4/17/05, Yuriy Tsibizov wrote: > On -CURRENT from Saturday, D-Link DWL-G650+ (TNET1130 chipset) NDIS [snip] > ndis0: mem > 0xe6000000-0xe6001fff,0xe5800000-0xe581ffff irq 9 at device 10.0 on pci0 > ndis0: [GIANT-LOCKED] > ndis0: NDIS API version: 5.0 > kernel trap 9 with interrupts disabled Noticed this today myself with > ndis0: mem 0xfcffe000-0= xfcffefff irq 9 at device 3.0 on pci1 > ndis0: NDIS API version: 5.1 > ndis0: Ethernet address: 00:0e:35:17:f2:88 > ndis0: couldn't retrieve channel info: 19 > ndis0: link up My x86 foo is a little rusty, but I think Peter Wemm's changes to the segment layout conflicted with the NDIS driver, such that the NDIS driver now tramples on the code segment for the process's user mode, rather than it's own private GDT entry. The attached patch works for me: can you try it? Peter/Bill: does this look correct? Cheers, Peadar. ------=_Part_17616_4427029.1113761444939 Content-Type: text/plain; name="ndispatch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ndispatch.txt" SW5kZXg6IGNvbXBhdC9uZGlzL2tlcm5fd2luZHJ2LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vz ci9jdnMvRnJlZUJTRC1DVlMvc3JjL3N5cy9jb21wYXQvbmRpcy9rZXJuX3dpbmRydi5jLHYKcmV0 cmlldmluZyByZXZpc2lvbiAxLjYKZGlmZiAtdSAtcjEuNiBrZXJuX3dpbmRydi5jCi0tLSBjb21w YXQvbmRpcy9rZXJuX3dpbmRydi5jCTExIEFwciAyMDA1IDAyOjAyOjM0IC0wMDAwCTEuNgorKysg Y29tcGF0L25kaXMva2Vybl93aW5kcnYuYwkxNyBBcHIgMjAwNSAxODowODozMyAtMDAwMApAQCAt NTksNiArNTksOSBAQAogI2luY2x1ZGUgPGNvbXBhdC9uZGlzL25kaXNfdmFyLmg+CiAjaW5jbHVk ZSA8Y29tcGF0L25kaXMvaGFsX3Zhci5oPgogI2luY2x1ZGUgPGNvbXBhdC9uZGlzL3VzYmRfdmFy Lmg+CisjaWZkZWYgX19pMzg2X18KKyNpbmNsdWRlIDxtYWNoaW5lL3NlZ21lbnRzLmg+CisjZW5k aWYKIAogc3RydWN0IHdpbmRydl90eXBlIHsKIAl1aW50MTZfdAkJd2luZHJ2X3ZpZDsJLyogZm9y IFBDSSBvciBVU0IgKi8KQEAgLTU0NSw3ICs1NDgsNiBAQAogCiAjZGVmaW5lIFNFTF9MRFQJNAkJ LyogbG9jYWwgZGVzY3JpcHRvciB0YWJsZSAqLwogI2RlZmluZSBTRUxfVE9fRlMoeCkJCSgoKHgp IDw8IDMpKQotI2RlZmluZSBGUkVFQlNEX0VNUFRZU0VMCTcKIAogLyoKICAqIFRoZSBtZWFuaW5n cyBvZiB2YXJpb3VzIGJpdHMgaW4gYSBkZXNjcmlwdG9yIHZhcnkgYSBsaXR0bGUKQEAgLTc5NCw3 ICs3OTYsNyBAQAogCS8qIEZpbmQgdGhlIHNsb3Qgd2UgdXBkYXRlZC4gKi8KIAogCWdkdCA9IGd0 YWJsZS5iYXNlOwotCWdkdCArPSBGUkVFQlNEX0VNUFRZU0VMOworCWdkdCArPSBHTkRJU19TRUw7 CiAKIAkvKiBFbXB0eSBpdCBvdXQuICovCiAKQEAgLTgzMiwxMSArODM0LDExIEBACiAKIAkvKiBH ZXQgcG9pbnRlciB0byBlbXB0eSBzbG90ICovCiAKLQlsICs9IEZSRUVCU0RfRU1QVFlTRUw7CisJ bCArPSBHTkRJU19TRUw7CiAKIAkvKiBJbml0aWFsaXplIFRJRCBmb3IgdGhpcyBDUFUuICovCiAK LQlteV90aWRzW3QtPnRkX29uY3B1XS50aWRfc2VsZWN0b3IgPSBGUkVFQlNEX0VNUFRZU0VMOwor CW15X3RpZHNbdC0+dGRfb25jcHVdLnRpZF9zZWxlY3RvciA9IEdORElTX1NFTDsKIAlteV90aWRz W3QtPnRkX29uY3B1XS50aWRfc2VsZiA9ICZteV90aWRzW3QtPnRkX29uY3B1XTsKIAogCS8qIFNl dCB1cCBuZXcgR0RUIGVudHJ5LiAqLwo= ------=_Part_17616_4427029.1113761444939-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 18:29:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5D3D16A4E4 for ; Sun, 17 Apr 2005 18:29:10 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F09D43D4C for ; Sun, 17 Apr 2005 18:29:10 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNEW3-0004Eb-2Z for current@freebsd.org; Sun, 17 Apr 2005 20:29:09 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3HIT2ZO002394; Sun, 17 Apr 2005 20:29:02 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John-Mark Gurney From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 17 Apr 2005 10:52:25 PDT." <20050417175225.GC16099@funkthat.com> Date: Sun, 17 Apr 2005 20:29:02 +0200 Message-ID: <2393.1113762542@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org cc: Ivan Voras Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 18:29:10 -0000 In message <20050417175225.GC16099@funkthat.com>, John-Mark Gurney writes: >Ivan Voras wrote this message on Sun, Apr 17, 2005 at 01:02 +0200: >> Poul-Henning Kamp wrote: >> >> >The reason gstat shows >100% busy is that there are some outstanding >> >requests. (the 2 in the left hand column). >> > >> >I tried to make the statistics collection as cheap as possible, and >> >as a side effect some of the columns can be somewhat misleading. >> >> Could it be (for reasons of prettyfication) clipped to [0-100] range? >> Something like in the attached? > >It could, but IMO, leaving them unclipped will continue to show that >the numbers are complete apporimations and not to be depended upon.. >If they were to always show 0-100%, people might start putting more >meaning into them than is really there (as phk enumerated in a previous >message)... Right, that's why they are not clipped today. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 18:49:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7687E16A4CE; Sun, 17 Apr 2005 18:49:05 +0000 (GMT) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D8E243D46; Sun, 17 Apr 2005 18:49:04 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.50 (FreeBSD)) id 1DNEmO-0000Nu-CL; Sun, 17 Apr 2005 22:46:00 +0400 From: Vladimir Grebenschikov To: "M. Warner Losh" In-Reply-To: <20050417.111015.77928634.imp@bsdimp.com> References: <1113740156.1018.6.camel@localhost> <20050417.111015.77928634.imp@bsdimp.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sun, 17 Apr 2005 22:45:59 +0400 Message-Id: <1113763560.1005.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: mobile@freebsd.org cc: current@freebsd.org Subject: Re: devd + driver load by plugged device class how to ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 18:49:05 -0000 =F7 =D7=D3, 17/04/2005 =D7 11:10 -0600, M. Warner Losh =D0=C9=DB=C5=D4: > In message: <1113740156.1018.6.camel@localhost> > Vladimir Grebenschikov writes: > : Is there way to configure devd (or other daemon) to load appropriate > : driver by class, when device detected on bus, like: >=20 > Yes. That's what nomatch events are for. The default devd.conf > momatch entries in it. >=20 > : load ukbd.ko when USB keyboard plugged (same for other USB ums, ulpt, > : umass, etc) >=20 > usb doesn't support reprobing correctly yet, so this isn't possible > until it does. >=20 > : load atacard.ko, when ATA disk inserted into PCMCI slot >=20 > nomatch 10 { > match "bus" "pccard[0-9]+]; > match "function_type" "4"; > action "kldload atacard"; > } >=20 > : load if_wi.ko when WLan card inserted into PCMCI slot=20 >=20 > This device supports a large number of devices, so the list is rather > long... Oops, looks like there is some bugs here: # cat /etc/devd/atacard.conf nomatch 10 { match "bus" "pccard[0-9]+"; match "function_type" "4"; action "kldload atacard"; }; # cat /etc/devd/wi0.conf nomatch 10 { match "bus" "pccard[0-9]+"; match "manufacturer" "0x0156";=20 action "kldload if_wi"; }; # grep -C1 \$pnpinfo /etc/devd.conf nomatch 0 { action "logger Unknown device: pnp=3D$pnpinfo loc=3D$location bus= =3D$bus manufacturer=3D$manufacturer product=3D$product"; }; # devd -dD Parsing /etc/devd.conf ethernet-nic-regex=3D(an|ar|ath|aue|awi|axe|bfe|bge|cm|cnw|cs|cue|dc|de|ed|= el|em|ep|ex|fe|fxp|gem|hme|ie|kue|lge|lnc|my|nge|pcn|ray|re|rl|rue|sf|sis|s= k|sn|snc|ste|ti|tl|tx|txp|udav|vge|vr|vx|wb|wi|xe|xl)[0-9]+ scsi-controller-regex=3D(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|cis= s|ct|dpt|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)[0-9]+ Parsing files in /etc/devd Parsing /etc/devd/wi0.conf Parsing /etc/devd/iwi.conf Parsing /etc/devd/acpi_power.conf Parsing /etc/devd/atacard.conf Parsing files in /usr/local/etc/devd // PCMCI CDROM inserted here=20 Processing event '? at function=3D0 manufacturer=3D0xffffffff product=3D0xf= fffffff cisvendor=3D"Shining" cisproduct=3D"PMIDE-ASC" function_type=3D4 on= pccard0' Pushing table Processing nomatch event Testing bus=3D against ^pccard[0-9]+ Testing bus=3D against ^pccard[0-9]+ Executing 'logger Unknown device: pnp=3D loc=3D bus=3D manufacturer=3D prod= uct=3D' Popping table // WaveLan inserted here Processing event '? at function=3D0 manufacturer=3D0x0156 product=3D0x0002 = cisvendor=3D"Lucent Technologies" cisproduct=3D"WaveLAN/IEEE" function_type= =3D6 on pccard0' Pushing table Processing nomatch event Testing bus=3D against ^pccard[0-9]+ Testing bus=3D against ^pccard[0-9]+ Executing 'logger Unknown device: pnp=3D loc=3D bus=3D manufacturer=3D prod= uct=3D' Popping table // Looks like: - bus name does not substituted, see "Testing bus=3D against ^pccard[0-9]+" messages, kernel reports valid messages: pccard0: (manufacturer=3D0xffffffff, product=3D0xffffffff) a= t function 0 pccard0: CIS info: Shining, PMIDE-ASC, Rev 1.04 pccard0: (manufacturer=3D0x0156, product=3D0x0002) at functi= on 0 pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01 - variables does not interpreted, see "nomatch 0" entry above, I've extend it with "manufacturer=3D$manufacturer product=3D$product", but default devd.conf does not works also. > Warner --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 18:57:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9390816A4CE; Sun, 17 Apr 2005 18:57:53 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EABB43D41; Sun, 17 Apr 2005 18:57:52 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3HIvpNc016992; Sun, 17 Apr 2005 13:57:51 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4262B185.7080100@centtech.com> Date: Sun, 17 Apr 2005 13:57:09 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Santcroos References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> In-Reply-To: <20050414172147.GA772@laptop.santcroos.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 18:57:53 -0000 Mark Santcroos wrote: > On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: > >>looks like acopcode.h and acnames.h are not included in the patch. > > > Oops, rusty cvs skills :) > > The following files have been added to the diff: > abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c > aemain.c osunixdir.c > > Same location, more fun: > http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz I just applied this patch, and everything seems to run ok. Only thing I noticed was that I get pauses now about every 6 seconds. All my recent dmesg/sysctl/etc output is here: http://googlebit.com/freebsd/ Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 19:06:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B55716A4CE for ; Sun, 17 Apr 2005 19:06:17 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 375D743D31 for ; Sun, 17 Apr 2005 19:06:17 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id D1B2C78C62; Sun, 17 Apr 2005 15:07:42 -0400 (EDT) Received: from pandora.afflictions.org ([127.0.0.1]) by localhost (pandora.afflictions.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94601-01; Sun, 17 Apr 2005 15:06:03 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) by pandora.afflictions.org (Postfix) with ESMTP id 3107278C35; Sun, 17 Apr 2005 15:06:00 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id C7CC533C60; Sun, 17 Apr 2005 15:05:34 -0400 (EDT) Date: Sun, 17 Apr 2005 15:05:34 -0400 From: Damian Gerow To: Tofik Suleymanov Message-ID: <20050417190534.GC51599@afflictions.org> Mail-Followup-To: Tofik Suleymanov , Jeffrey , freebsd-current@freebsd.org References: <20050416154321.42E1243D58@mx1.FreeBSD.org> <42617480.5080903@oxygen.az> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42617480.5080903@oxygen.az> X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at pandora.afflictions.org cc: freebsd-current@freebsd.org cc: Jeffrey Subject: Re: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 19:06:17 -0000 Thus spake Tofik Suleymanov (tofik@oxygen.az) [17/04/05 08:05]: : >Does anyone know more about support for the promise fasttrak tx 4200? It : >isn't in the current. : : We've got fasttrack tx2200 (the same chipset as 4400) and it not : recognized at all on 5.3-RELEASE. : I am also interested in any information about support of this hardware : on RELENG_5. Have you tried applying the ATA mkIII patchset? I've been running with a TX2200 for a month handling NFS (albeit, low volume) and the patchset without any issues whatsoever, and the card is fully supported. - Damian From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 19:19:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 32E9F16A4CF; Sun, 17 Apr 2005 19:19:48 +0000 (GMT) In-Reply-To: <34cb7c840504171110737bba62@mail.gmail.com> from Peter Edwards at "Apr 17, 2005 07:10:44 pm" To: peadar.edwards@gmail.com (Peter Edwards) Date: Sun, 17 Apr 2005 19:19:48 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050417191948.32E9F16A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: Yuriy.Tsibizov@gfk.ru cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: if_ndis: kernel trap 9 with interrupts disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 19:19:48 -0000 [Charset ISO-8859-1 unsupported, filtering to ASCII...] > On 4/17/05, Yuriy Tsibizov wrote: > > > On -CURRENT from Saturday, D-Link DWL-G650+ (TNET1130 chipset) NDIS > [snip] > > ndis0: mem > > 0xe6000000-0xe6001fff,0xe5800000-0xe581ffff irq 9 at device 10.0 on pci0 > > ndis0: [GIANT-LOCKED] > > ndis0: NDIS API version: 5.0 > > kernel trap 9 with interrupts disabled > > Noticed this today myself with > > > ndis0: mem 0xfcffe000-0xfcffefff irq 9 at device 3.0 on pci1 > > ndis0: NDIS API version: 5.1 > > ndis0: Ethernet address: 00:0e:35:17:f2:88 > > ndis0: couldn't retrieve channel info: 19 > > ndis0: link up > > My x86 foo is a little rusty, but I think Peter Wemm's changes to the > segment layout conflicted with the NDIS driver, such that the NDIS > driver now tramples on the code segment for the process's user mode, > rather than it's own private GDT entry. The attached patch works for > me: can you try it? > Peter/Bill: does this look correct? > > Cheers, > Peadar. Your fix is correct, but it fails to take into account backwards source compatibility with previous versions of FreeBSD. I'll clean this up and check it in presently. (I am desperately trying to fix is so that the code in sys/compat/ndis is synched between stable and current so I don't have to maintain two separate trees.) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Sun Apr 17 21:32:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3729516A4CE; Sun, 17 Apr 2005 21:32:33 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC7E343D2D; Sun, 17 Apr 2005 21:32:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3HLTdWe046052; Sun, 17 Apr 2005 15:29:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Apr 2005 15:29:44 -0600 (MDT) Message-Id: <20050417.152944.63048219.imp@bsdimp.com> To: vova@fbsd.ru From: "M. Warner Losh" In-Reply-To: <1113763560.1005.9.camel@localhost> References: <1113740156.1018.6.camel@localhost> <20050417.111015.77928634.imp@bsdimp.com> <1113763560.1005.9.camel@localhost> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mobile@freebsd.org cc: current@freebsd.org Subject: Re: devd + driver load by plugged device class how to ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 21:32:33 -0000 OK. I'll have to look into it. I know this worked at one time. Warner From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 00:34:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 968AD16A4CE for ; Mon, 18 Apr 2005 00:34:20 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9BB343D41 for ; Mon, 18 Apr 2005 00:34:19 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so1393698nzf for ; Sun, 17 Apr 2005 17:34:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=E3av4I2uGOsGq0G+wj0bVwaCL6bJzwUqbdhKMp3smmMBZErncC+fck9VckYVXoh2uzE7EOUPq8VwR3Wqn2WOjRYIoQfVfN+C4Le9OXD1kOaGXthQTPw57rczjrpKo08Q5t/Qo/NOaDwo3mUij44fxw6sHS8g7YwtNb0RB61NDoA= Received: by 10.36.25.2 with SMTP id 2mr325117nzy; Sun, 17 Apr 2005 17:34:19 -0700 (PDT) Received: by 10.36.68.4 with HTTP; Sun, 17 Apr 2005 17:34:19 -0700 (PDT) Message-ID: <34cb7c8405041717342891f2@mail.gmail.com> Date: Mon, 18 Apr 2005 01:34:19 +0100 From: Peter Edwards To: Greg 'groggy' Lehey , FreeBSD Current In-Reply-To: <20050214014217.GB85932@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18724_15726492.1113784459091" References: <20050214014217.GB85932@wantadilla.lemis.com> Subject: Re: Race condition in debugger? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 00:34:20 -0000 ------=_Part_18724_15726492.1113784459091 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Very late response: I just experienced the same problem and remembered the issue had been brought up before] On 2/14/05, Greg 'groggy' Lehey wrote: > I'm having some problems with userland gdb on recent -CURRENT builds: > at some point it hangs. >=20 > Specifically, I'm setting a conditional breakpoint like this: >=20 > b Minsert_blockletpointer if I->inode_num =3D=3D 0x1f0bb >=20 > inode_num increments for 1, so I hit this breakpoint about 100,000 > times. Or I should. What happens is that the debugger hangs at some > point on the way. ktrace shows multiple copies of: >=20 > 12325 gdb CALL ptrace(12,0x3026,0xbfbfd5e0,0) > 12325 gdb RET ptrace 0 > 12325 gdb CALL ptrace(PT_STEP,0x3026,0x1,0) > 12325 gdb RET ptrace 0 > 12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0) <-- stops here > 12325 gdb RET wait4 12326/0x3026 > 12325 gdb CALL kill(0x3026,0) > 12325 gdb RET kill 0 > 12325 gdb CALL ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0) >=20 > When it hangs, it's at the call to wait4, as shown. It looks like the > completion of the ptrace request isn't being reported back. I think I know what's going on with this, and I have a feeling that there's a couple of other wait()-related issues that were left open on the lists that might be explained by the issue. Here's my hypothesis: kern_wait() checks each child of the current process to see if they have exited, or should otherwise report status to wait/wait3/wait4/waitpid, If it finds that all candidate children have nothing to report, it goes asleep, waiting to be awoken by the/a child reporting status, and repeats the process: it looks a bit like this: kern_wait() { loop: foreach child of self { if (child has status to report) return status; } lock self msleep(on "self") unlock self goto loop; } Problem is, that there's no lock protecting that the conditions in the inner loop hold by the time the current process locks its own "struct proc" and invokes msleep(). (It's probably most likely the race will happen on an SMP machine or with PREEMPTION, but the aquiry of curproc's lock could possibly cause the issue if it needed to sleep.), i.e., you can miss the wakeup generated by a particular child between checking the process in the inner loop, and going to sleep. I can at least reproduce this for the ptrace/gdb case, but AFAICT, it could happen for the standard wait()/exit() path, too. I worked up a patch to fix the problem by having those parts of the kernel that wake the process up flag the fact in the parent's flags and doing the wakeup while holding tha parent process lock, and noticing if this flag has been set before sleeping. (A simpler solution would be to hold the parent lock across the bulk of kern_wait, but from what I can gather this will lead to at least one LOR) I've been unable to reproduce the problem with a kernel with this patch, and using a nice sprinkling of printfs can show that when GDB hangs, the race has just occurred. Anyone got opinions on this? Cheers, Peadar. ------=_Part_18724_15726492.1113784459091 Content-Type: text/plain; name="waitpatch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="waitpatch.txt" SW5kZXg6IGtlcm4va2Vybl9leGl0LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9jdnMvRnJl ZUJTRC1DVlMvc3JjL3N5cy9rZXJuL2tlcm5fZXhpdC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjI1NwpkaWZmIC11IC1yMS4yNTcga2Vybl9leGl0LmMKLS0tIGtlcm4va2Vybl9leGl0LmMJMTMg TWFyIDIwMDUgMTE6NDc6MDQgLTAwMDAJMS4yNTcKKysrIGtlcm4va2Vybl9leGl0LmMJMTggQXBy IDIwMDUgMDA6MDg6MzAgLTAwMDAKQEAgLTU3Miw2ICs1NzIsNyBAQAogCXJldHVybiAoZXJyb3Ip OwogfQogCitpbnQgZml4cmFjZSA9IDE7CiBpbnQKIGtlcm5fd2FpdChzdHJ1Y3QgdGhyZWFkICp0 ZCwgcGlkX3QgcGlkLCBpbnQgKnN0YXR1cywgaW50IG9wdGlvbnMsCiAgICAgc3RydWN0IHJ1c2Fn ZSAqcnVzYWdlKQpAQCAtNzM5LDcgKzc0MCwxMSBAQAogCX0KIAlQUk9DX0xPQ0socSk7CiAJc3hf eHVubG9jaygmcHJvY3RyZWVfbG9jayk7Ci0JZXJyb3IgPSBtc2xlZXAocSwgJnEtPnBfbXR4LCBQ V0FJVCB8IFBDQVRDSCwgIndhaXQiLCAwKTsKKwlpZiAoZml4cmFjZSA9PSAwIHx8IChxLT5wX2Zs YWcgJiBQX1NUQVRDSElMRCkgPT0gMCkKKwkJZXJyb3IgPSBtc2xlZXAocSwgJnEtPnBfbXR4LCBQ V0FJVCB8IFBDQVRDSCwgIndhaXQiLCAwKTsKKwllbHNlCisJCWVycm9yID0gMDsKKwlxLT5wX2Zs YWcgJj0gflBfU1RBVENISUxEOwogCVBST0NfVU5MT0NLKHEpOwogCWlmIChlcnJvcikKIAkJcmV0 dXJuIChlcnJvcik7CQpJbmRleDoga2Vybi9rZXJuX3NpZy5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6 IC91c3IvY3ZzL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMva2Vybi9rZXJuX3NpZy5jLHYKcmV0cmlldmlu ZyByZXZpc2lvbiAxLjMwNApkaWZmIC11IC1yMS4zMDQga2Vybl9zaWcuYwotLS0ga2Vybi9rZXJu X3NpZy5jCTEwIEFwciAyMDA1IDAyOjMxOjI0IC0wMDAwCTEuMzA0CisrKyBrZXJuL2tlcm5fc2ln LmMJMTggQXByIDIwMDUgMDA6MDg6MzEgLTAwMDAKQEAgLTcxLDYgKzcxLDcgQEAKICNpbmNsdWRl IDxzeXMvc3lzcHJvdG8uaD4KICNpbmNsdWRlIDxzeXMvdW5pc3RkLmg+CiAjaW5jbHVkZSA8c3lz L3dhaXQuaD4KKyNpbmNsdWRlIDxzeXMva2RiLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2NwdS5o PgogCkBAIC0yMjU5LDggKzIyNjAsMTAgQEAKIHsKIAogCVBST0NfTE9DS19BU1NFUlQocCwgTUFf T1dORUQpOworCVBST0NfTE9DS19BU1NFUlQocC0+cF9wcHRyLCBNQV9PV05FRCk7CiAJcC0+cF9m bGFnIHw9IFBfU1RPUFBFRF9TSUc7CiAJcC0+cF9mbGFnICY9IH5QX1dBSVRFRDsKKwlwLT5wX3Bw dHItPnBfZmxhZyB8PSBQX1NUQVRDSElMRDsKIAl3YWtldXAocC0+cF9wcHRyKTsKIH0KIApAQCAt MjI4MSw4ICsyMjg0LDggQEAKIAkJbisrOwogCWlmICgocC0+cF9mbGFnICYgUF9TVE9QUEVEX1NJ RykgJiYgKG4gPT0gcC0+cF9udW10aHJlYWRzKSkgewogCQltdHhfdW5sb2NrX3NwaW4oJnNjaGVk X2xvY2spOwotCQlzdG9wKHApOwogCQlQUk9DX0xPQ0socC0+cF9wcHRyKTsKKwkJc3RvcChwKTsK IAkJcHMgPSBwLT5wX3BwdHItPnBfc2lnYWN0czsKIAkJbXR4X2xvY2soJnBzLT5wc19tdHgpOwog CQlpZiAoKHBzLT5wc19mbGFnICYgUFNfTk9DTERTVE9QKSA9PSAwKSB7CkluZGV4OiBzeXMvcHJv Yy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC91c3IvY3ZzL0ZyZWVCU0QtQ1ZTL3NyYy9zeXMvc3lz L3Byb2MuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40MjQKZGlmZiAtdSAtcjEuNDI0IHByb2Mu aAotLS0gc3lzL3Byb2MuaAk4IEFwciAyMDA1IDAzOjM3OjUyIC0wMDAwCTEuNDI0CisrKyBzeXMv cHJvYy5oCTE4IEFwciAyMDA1IDAwOjA4OjQ0IC0wMDAwCkBAIC02MzYsNiArNjM2LDcgQEAKICNk ZWZpbmUJUF9TSU5HTEVfQk9VTkRBUlkgMHg0MDAwMDAgLyogVGhyZWFkcyBzaG91bGQgc3VzcGVu ZCBhdCB1c2VyIGJvdW5kYXJ5LiAqLwogI2RlZmluZQlQX0pBSUxFRAkweDEwMDAwMDAgLyogUHJv Y2VzcyBpcyBpbiBqYWlsLiAqLwogI2RlZmluZQlQX0lORVhFQwkweDQwMDAwMDAgLyogUHJvY2Vz cyBpcyBpbiBleGVjdmUoKS4gKi8KKyNkZWZpbmUJUF9TVEFUQ0hJTEQJMHg4MDAwMDAwIC8qIEEg Y2hpbGQgaGFzIHN0YXR1cyB0byByZXBvcnQuICovCiAKICNkZWZpbmUJUF9TVE9QUEVECShQX1NU T1BQRURfU0lHfFBfU1RPUFBFRF9TSU5HTEV8UF9TVE9QUEVEX1RSQUNFKQogI2RlZmluZQlQX1NI T1VMRFNUT1AocCkJKChwKS0+cF9mbGFnICYgUF9TVE9QUEVEKQo= ------=_Part_18724_15726492.1113784459091-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 02:16:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A4F116A4CE; Mon, 18 Apr 2005 02:16:33 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D5F343D2D; Mon, 18 Apr 2005 02:16:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3I2GVoc012393; Sun, 17 Apr 2005 22:16:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3I2GloK017733; Sun, 17 Apr 2005 22:16:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 058CB7306E; Sun, 17 Apr 2005 22:16:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050418021630.058CB7306E@freebsd-current.sentex.ca> Date: Sun, 17 Apr 2005 22:16:30 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 02:16:33 -0000 TB --- 2005-04-18 00:38:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-18 00:38:45 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-18 00:38:45 - checking out the source tree TB --- 2005-04-18 00:38:45 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-18 00:38:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-18 00:45:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-18 00:45:46 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-18 00:45:46 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-18 01:53:53 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-18 01:53:53 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-18 01:53:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Apr 18 01:53:53 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Apr 18 02:05:49 UTC 2005 TB --- 2005-04-18 02:05:49 - generating LINT kernel config TB --- 2005-04-18 02:05:49 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-04-18 02:05:49 - /usr/bin/make -B LINT TB --- 2005-04-18 02:05:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-18 02:05:49 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-18 02:05:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 18 02:05:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/ofw _pcibus.c awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/ofw_pci_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large- function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror ofw_pci_if.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/psy cho.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sbus/sb us.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sbus/ls i64854.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sbus/lsi64854.c: In function `lsi64854_pp_intr': /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sbus/lsi64854.c:659: warning: format argument is not a pointer (arg 5) /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/sbus/lsi64854.c:659: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-18 02:16:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-18 02:16:30 - ERROR: failed to build lint kernel TB --- 2005-04-18 02:16:30 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 02:59:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED1DE16A4CE; Mon, 18 Apr 2005 02:59:40 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 852AD43D2D; Mon, 18 Apr 2005 02:59:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3I2w8Jw048880; Sun, 17 Apr 2005 20:58:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 17 Apr 2005 20:58:14 -0600 (MDT) Message-Id: <20050417.205814.91782143.imp@bsdimp.com> To: vova@fbsd.ru From: "M. Warner Losh" In-Reply-To: <1113763560.1005.9.camel@localhost> References: <1113740156.1018.6.camel@localhost> <20050417.111015.77928634.imp@bsdimp.com> <1113763560.1005.9.camel@localhost> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mobile@freebsd.org cc: current@freebsd.org Subject: Re: devd + driver load by plugged device class how to ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 02:59:41 -0000 Doh! I've just fixed the bug that caused this... Warner From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 03:30:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D430316A4CE; Mon, 18 Apr 2005 03:30:54 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B1443D54; Mon, 18 Apr 2005 03:30:54 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.250] (adsl-64-171-187-46.dsl.snfc21.pacbell.net [64.171.187.46]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j3I3UpLS008850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Apr 2005 20:30:52 -0700 Message-ID: <426329E6.4090105@root.org> Date: Sun, 17 Apr 2005 20:30:46 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <4262B185.7080100@centtech.com> In-Reply-To: <4262B185.7080100@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 03:30:55 -0000 Eric Anderson wrote: > Mark Santcroos wrote: > >> On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: >> >>> looks like acopcode.h and acnames.h are not included in the patch. >> >> >> >> Oops, rusty cvs skills :) >> >> The following files have been added to the diff: >> abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c >> aemain.c osunixdir.c >> >> Same location, more fun: >> http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz > > > I just applied this patch, and everything seems to run ok. > > Only thing I noticed was that I get pauses now about every 6 seconds. > All my recent dmesg/sysctl/etc output is here: > > http://googlebit.com/freebsd/ > > Eric Is there any difference in the embedded controller? You have to boot without -v to see its messages (they scrolled in your output). Any new warning messages when you get the pause? -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 05:26:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07A5216A4CE; Mon, 18 Apr 2005 05:26:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC6C43D45; Mon, 18 Apr 2005 05:26:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3I5Q4Ni024018; Mon, 18 Apr 2005 05:26:05 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42634514.2090902@freebsd.org> Date: Mon, 18 Apr 2005 13:26:44 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050214014217.GB85932@wantadilla.lemis.com> <34cb7c8405041717342891f2@mail.gmail.com> In-Reply-To: <34cb7c8405041717342891f2@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Greg 'groggy' Lehey cc: FreeBSD Current Subject: Re: Race condition in debugger? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 05:26:07 -0000 Peter Edwards wrote: >[Very late response: I just experienced the same problem and >remembered the issue had been brought up before] > >On 2/14/05, Greg 'groggy' Lehey wrote: > > >>I'm having some problems with userland gdb on recent -CURRENT builds: >>at some point it hangs. >> >>Specifically, I'm setting a conditional breakpoint like this: >> >> b Minsert_blockletpointer if I->inode_num == 0x1f0bb >> >>inode_num increments for 1, so I hit this breakpoint about 100,000 >>times. Or I should. What happens is that the debugger hangs at some >>point on the way. ktrace shows multiple copies of: >> >> 12325 gdb CALL ptrace(12,0x3026,0xbfbfd5e0,0) >> 12325 gdb RET ptrace 0 >> 12325 gdb CALL ptrace(PT_STEP,0x3026,0x1,0) >> 12325 gdb RET ptrace 0 >> 12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0) <-- stops here >> 12325 gdb RET wait4 12326/0x3026 >> 12325 gdb CALL kill(0x3026,0) >> 12325 gdb RET kill 0 >> 12325 gdb CALL ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0) >> >>When it hangs, it's at the call to wait4, as shown. It looks like the >>completion of the ptrace request isn't being reported back. >> >> > >I think I know what's going on with this, and I have a feeling that >there's a couple of other wait()-related issues that were left open on >the lists that might be explained by the issue. > >Here's my hypothesis: kern_wait() checks each child of the current >process to see if they have exited, or should otherwise report status >to wait/wait3/wait4/waitpid, If it finds that all candidate children >have nothing to report, it goes asleep, waiting to be awoken by the/a >child reporting status, and repeats the process: it looks a bit like >this: > >kern_wait() >{ >loop: > foreach child of self { > if (child has status to report) > return status; > } > lock self > msleep(on "self") > unlock self > goto loop; >} > >Problem is, that there's no lock protecting that the conditions in the >inner loop hold by the time the current process locks its own "struct >proc" and invokes msleep(). (It's probably most likely the race will >happen on an SMP machine or with PREEMPTION, but the aquiry of >curproc's lock could possibly cause the issue if it needed to sleep.), >i.e., you can miss the wakeup generated by a particular child between >checking the process in the inner loop, and going to sleep. > >I can at least reproduce this for the ptrace/gdb case, but AFAICT, it >could happen for the standard wait()/exit() path, too. I worked up a >patch to fix the problem by having those parts of the kernel that wake >the process up flag the fact in the parent's flags and doing the >wakeup while holding tha parent process lock, and noticing if this >flag has been set before sleeping. (A simpler solution would be to >hold the parent lock across the bulk of kern_wait, but from what I can >gather this will lead to at least one LOR) > >I've been unable to reproduce the problem with a kernel with this >patch, and using a nice sprinkling of printfs can show that when GDB >hangs, the race has just occurred. > >Anyone got opinions on this? >Cheers, >Peadar. > > If the parent has PS_NOCLDSTOP set, no SIGCHLD will be sent to parent, so there is race in the case, but if PS_NOCLDSTOP is set, the signal will be sent to parent, and parant should resume from msleep() immediately. I don't know why it still does have race, I am looking the code, I think stop() should be merged into thread_stopped(), there is no another caller at all. David Xu From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 06:26:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5797816A4CE for ; Mon, 18 Apr 2005 06:26:34 +0000 (GMT) Received: from web54006.mail.yahoo.com (web54006.mail.yahoo.com [206.190.36.230]) by mx1.FreeBSD.org (Postfix) with SMTP id A819943D48 for ; Mon, 18 Apr 2005 06:26:33 +0000 (GMT) (envelope-from spamrefuse@yahoo.com) Received: (qmail 64377 invoked by uid 60001); 18 Apr 2005 06:26:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Bu7QUEVV5dOj5N1x95NrZVe6mQNdJ2S1GCwdtr+HkHwuyU40cwl8jHRHEimfcOS2ymDYtoX0jlidRrpUdeXzyX6LeBuhhoeX6QDHeHoAiMFDeSkyjZjStPj8hus5oryhY6BJjNUfnt0UXWLSqIq96hue4C8XNn7amOq096sRjBo= ; Message-ID: <20050418062633.64375.qmail@web54006.mail.yahoo.com> Received: from [147.46.44.181] by web54006.mail.yahoo.com via HTTP; Sun, 17 Apr 2005 23:26:33 PDT Date: Sun, 17 Apr 2005 23:26:33 -0700 (PDT) From: Rob To: ru@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD current Subject: DEVICE_POLLING is not compatible with SMP? (was: xl(4) & polling) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 06:26:34 -0000 Ruslan Ermilov wrote: > On Sun, Apr 10, Rob wrote: > >>--- Ruslan Ermilov wrote: >> >>>On Sat, Apr 09, Rob wrote: >>> >>>>PS: if this makes it into the official sources, >>>>then don't forget to also add xl(4) to the >>>>polling(4) manpage. >>> >>>It did (last month). The manpage was also updated. >> >>Will it also go into RELENG_5, after the 5.4 release? >> > > Yes, probably. After I hear more reports of success. > The HEAD sources can be used on RELENG_5 to test the > functionality. I found xl polling was committed to RELENG_5. Very good indeed! So I have also tried to enable polling on another PC with xl LAN and SMP, but the kernel compilation stops with: #error DEVICE_POLLING is not compatible with SMP Is this error message still relevant? Rob. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 07:26:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BEEC16A4CE; Mon, 18 Apr 2005 07:26:44 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E256C43D2D; Mon, 18 Apr 2005 07:26:42 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3I7Qdjk004678 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 18 Apr 2005 09:26:40 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3I7Qd1I004677; Mon, 18 Apr 2005 09:26:39 +0200 (CEST) Date: Mon, 18 Apr 2005 09:26:39 +0200 From: Divacky Roman To: John Baldwin Message-ID: <20050418072639.GA4635@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: current@FreeBSD.org Subject: Re: slow kbd input on 6-current on amd64@nforce3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 07:26:44 -0000 hi, I sent you an-email about this... can you pls advice me? (where to change that triggering).. I tried to put some debuging printfs into /sys/amd64/amd64/intr_machdep.c:intr_config_inter() but nothing was printed on boot, so I am lost ;( thnx for info On Tue, Apr 12, 2005 at 12:53:50PM -0400, John Baldwin wrote: > On Tuesday 12 April 2005 03:38 am, Divacky Roman wrote: > > On Mon, Apr 11, 2005 at 08:38:32PM -0400, John Baldwin wrote: > > > On Wednesday 06 April 2005 09:09 am, Divacky Roman wrote: > > > > as I have mentioned on the list I have very slow keyboard input. it > > > > might be related to kbd not having an IRQ assigned. I repeat once again > > > > that it worked on 5.3R. > > > > > > Actually, now that I look at this, you have a buggy BIOS. It is lying > > > and claiming that some PCI interrupts are active-hi rather than > > > active-low. Hmm, the 5.3 dmesg you gave me included APIC, while this one > > > does not. Does disabling ACPI make your keyboard happy on 6.0 by chance? > > > > It doesnt boot with acpi enabled (stops in probing ata devices, but it > > never worked so I think ata is not the only culprit) > > Ok. > > > what can I do with it? would some quirk made the trick? why it worked in > > 5.3R? > > I don't know at this point. Does 6.0 in any configuration work ok? > (ACPI !APIC, ACPI APIC, !ACPI APIC, !ACPI !APIC) > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 09:25:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28D4616A4CE; Mon, 18 Apr 2005 09:25:52 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F14B43D4C; Mon, 18 Apr 2005 09:25:51 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 5A4451F007; Mon, 18 Apr 2005 11:25:50 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 3D63F6746; Mon, 18 Apr 2005 11:25:50 +0200 (CEST) Date: Mon, 18 Apr 2005 11:25:50 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050418092550.GA97539@stack.nl> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20050415150708.GP981@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 09:25:52 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2005 at 11:07:08AM -0400, Brian Fundakowski Feldman wrote: > > Is this supposed to fix kern/79208 ? >=20 > Yes, it does; would you like to try a more recent version of the patch? > It's actually against -STABLE, but it needs to be tested in -CURRENT if > it's going ot try to make it into 5.x (or hopefully 5.4-RELEASE). >=20 > See: Ok, I'll try it out on -CURRENT then. Marc --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCY30eezjnobFOgrERAqU3AJ99ygotgVaNgz9dOdxZGbmKTpVdigCfT+4V ytpYZ0f+780gZb7pm0lhnoM= =2N4b -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 11:48:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E00116A4CF for ; Mon, 18 Apr 2005 11:48:26 +0000 (GMT) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C86843D5C for ; Mon, 18 Apr 2005 11:48:25 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: from hadriel.linnet (wll192-81.wlan.hu-berlin.de [141.20.192.81]) (authenticated bits=0) (8.12.10/8.12.9/INF-2.0-MA-SOLARIS-2.8) with ESMTP id j3IBmNGR006077 for ; Mon, 18 Apr 2005 13:48:23 +0200 (MEST) Date: Mon, 18 Apr 2005 13:48:18 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> In-Reply-To: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> References: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 11:48:26 -0000 hi, do i understand it correctly that in adaptive mode powerd(8) jumps directly to max speed when increasing performance is necessary? why is it implemented in this way? (e.g. estctrl increased performance step by step ...) the currently implemented strategy caused the fan of my notebook to switch on within 15 min which it never did with estctrl running :( ... thx regards, seb From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 10:35:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 023C016A4CE for ; Mon, 18 Apr 2005 10:35:35 +0000 (GMT) Received: from smtp08.web.de (smtp08.web.de [217.72.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F5943D45 for ; Mon, 18 Apr 2005 10:35:34 +0000 (GMT) (envelope-from mueller.basti@web.de) Received: from [217.9.31.20] (helo=[192.168.0.14]) by smtp08.web.de with asmtp (WEB.DE 4.104 #268) id 1DNTbI-0003MO-00 for freebsd-current@freebsd.org; Mon, 18 Apr 2005 12:35:32 +0200 From: Sebastian =?ISO-8859-1?Q?M=FCller?= To: freebsd-current@freebsd.org Content-Type: text/plain Date: Mon, 18 Apr 2005 12:35:16 +0000 Message-Id: <1113827716.27675.17.camel@blaxx> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Sender: mueller.basti@web.de X-Sender: mueller.basti@web.de X-Mailman-Approved-At: Mon, 18 Apr 2005 11:55:56 +0000 Subject: I915 DRI Problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 10:35:35 -0000 Hi, i got a Intel 82855GME (855GME GMCH) SVGA controller. drm isn't working on FreeBSD 5.4-RC2. When i apply the patch submitted by: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2005-January/050894.html I get the output drmsub1: mem 0xfaf00000-0xfaf7ffff,0xe8000000-0xefffffff at device 2.1 on pci0 info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized i915 1.2.0 20041217 on minor 1 but it doesnt work properly. #dmesg | grep agp0 agp0: port 0xc000-0xc007 mem 0xfaf80000-0xfaffffff,0xf0000000-0xf7ffffff irq 11 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M #pciconf -vl agp0@pci0:2:0: class=0x030000 card=0x01631028 chip=0x35828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device' class = display subclass = VGA drmsub1@pci0:2:1: class=0x038000 card=0x01631028 chip=0x35828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82852GM/GME/GMV/PM, 855GM/GME Montara Integrated Graphics Device' class = display #scanpci -vv pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x3582 Intel Corp. 82852/855GM Integrated Graphics Device CardVendor 0x1028 card 0x0163 (Dell Computer Corporation, Card unknown) STATUS 0x0090 COMMAND 0x0007 CLASS 0x03 0x00 0x00 REVISION 0x02 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BASE0 0xf0000008 addr 0xf0000000 MEM PREFETCHABLE BASE1 0xfaf80000 addr 0xfaf80000 MEM BASE2 0x0000c001 addr 0x0000c000 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_0 0x09 BYTE_1 0x00 BYTE_2 0x05 BYTE_3 0x81 pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x3582 Intel Corp. 82852/855GM Integrated Graphics Device CardVendor 0x1028 card 0x0163 (Dell Computer Corporation, Card unknown) STATUS 0x0090 COMMAND 0x0007 CLASS 0x03 0x80 0x00 REVISION 0x02 BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00 BASE0 0xe8000008 addr 0xe8000000 MEM PREFETCHABLE BASE1 0xfaf00000 addr 0xfaf00000 MEM BYTE_0 0x09 BYTE_1 0x00 BYTE_2 0x05 BYTE_3 0x81 Maybe you can handle it. :) Cheers Sebastian From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 11:56:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 461D716A4D9 for ; Mon, 18 Apr 2005 11:56:06 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC5C43D1D for ; Mon, 18 Apr 2005 11:56:05 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id j3IBtw0x090770; Mon, 18 Apr 2005 13:56:00 +0200 Date: Mon, 18 Apr 2005 13:55:58 +0200 (CEST) From: Lukas Ertl To: sebastian ssmoller In-Reply-To: <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> Message-ID: <20050418135458.M53307@pcle2.cc.univie.ac.at> References: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx8 4248; Body=2 Fuz1=2 Fuz2=2 cc: freebsd-current@FreeBSD.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 11:56:06 -0000 On Mon, 18 Apr 2005, sebastian ssmoller wrote: > the currently implemented strategy caused the fan of my notebook to switch > on within 15 min which it never did with estctrl running :( ... I also noticed that powerd in adaptive mode keeps my laptop pretty warm. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:09:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA29F16A4CE; Mon, 18 Apr 2005 12:09:10 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC8F843D5C; Mon, 18 Apr 2005 12:09:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3IC98Vb055918; Mon, 18 Apr 2005 07:09:09 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4263A33A.3030201@centtech.com> Date: Mon, 18 Apr 2005 07:08:26 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukas Ertl References: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> <20050418135458.M53307@pcle2.cc.univie.ac.at> In-Reply-To: <20050418135458.M53307@pcle2.cc.univie.ac.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/837/Sun Apr 17 10:25:32 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:09:11 -0000 Lukas Ertl wrote: > On Mon, 18 Apr 2005, sebastian ssmoller wrote: > >> the currently implemented strategy caused the fan of my notebook to >> switch >> on within 15 min which it never did with estctrl running :( ... > > > I also noticed that powerd in adaptive mode keeps my laptop pretty warm. There's been some discussion on the -mobile list (I believe) about this kind of thing before. I think powerd is currently running with a 'best shot' configuration, and I'm pretty sure that if anyone has a better algorithm in a patch form for people to try, I'm certain the good people with commit bits would easily commit a patched better version. I've been looking at this over the weekend, and I have a few ideas, but I'm not a C coder, so it could take me to actually make a patch. :) If someone is willing to code it, I could send a stream of possible example ideas in 'brain dump' format, and then do testing. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:19:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C89C16A4CE; Mon, 18 Apr 2005 12:19:22 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C52443D49; Mon, 18 Apr 2005 12:19:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNVDi-0004HW-01; Mon, 18 Apr 2005 14:19:20 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3ICJEWv002305; Mon, 18 Apr 2005 14:19:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 18 Apr 2005 07:08:26 CDT." <4263A33A.3030201@centtech.com> Date: Mon, 18 Apr 2005 14:19:14 +0200 Message-ID: <2304.1113826754@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:19:22 -0000 In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: >Lukas Ertl wrote: > >There's been some discussion on the -mobile list (I believe) about >this kind of thing before. I think powerd is currently running with >a 'best shot' configuration, and I'm pretty sure that if anyone has >a better algorithm in a patch form for people to try, I'm certain the >good people with commit bits would easily commit a patched better version. I don't think a proportional approach will work in this case, the steps are too far apart. I also think the switch to full speed is wrong. Such see-saw algorithms waste far too much time decaying. A less steep flank should be used. For instance: if (idle > 90%) reduce clock one step. if (idle < 80%) increase clock two steps. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:27:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B81216A4CE for ; Mon, 18 Apr 2005 12:27:57 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACCA643D3F for ; Mon, 18 Apr 2005 12:27:56 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNVM3-00080U-0q for freebsd-current@freebsd.org; Mon, 18 Apr 2005 14:27:55 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3ICRrhn002429; Mon, 18 Apr 2005 14:27:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 18 Apr 2005 14:19:14 +0200." <2304.1113826754@critter.freebsd.dk> Date: Mon, 18 Apr 2005 14:27:53 +0200 Message-ID: <2428.1113827273@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:27:57 -0000 In message <2304.1113826754@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: >>Lukas Ertl wrote: >> >>There's been some discussion on the -mobile list (I believe) about >>this kind of thing before. I think powerd is currently running with >>a 'best shot' configuration, and I'm pretty sure that if anyone has >>a better algorithm in a patch form for people to try, I'm certain the >>good people with commit bits would easily commit a patched better version. > >I don't think a proportional approach will work in this case, the steps >are too far apart. > >I also think the switch to full speed is wrong. Such see-saw >algorithms waste far too much time decaying. A less steep flank >should be used. > >For instance: > > if (idle > 90%) > reduce clock one step. > if (idle < 80%) > increase clock two steps. Here's a patch which implements "phk" mode: Index: powerd.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/powerd/powerd.c,v retrieving revision 1.4 diff -u -r1.4 powerd.c --- powerd.c 27 Feb 2005 01:58:49 -0000 1.4 +++ powerd.c 18 Apr 2005 12:26:03 -0000 @@ -50,6 +50,7 @@ enum modes_t { MODE_MIN, MODE_ADAPTIVE, + MODE_PHK, MODE_MAX, }; @@ -220,6 +221,8 @@ *mode = MODE_MAX; else if (strcmp(arg, "adaptive") == 0) *mode = MODE_ADAPTIVE; + else if (strcmp(arg, "phk") == 0) + *mode = MODE_PHK; else errx(1, "bad option: -%c %s", (char)ch, optarg); } @@ -377,6 +380,37 @@ if (read_usage_times(&idle, &total)) err(1, "read_usage_times"); + if (mode == MODE_PHK) { + for (i = 0; i < numfreqs - 1; i++) { + if (freqs[i] == curfreq) + break; + } + if (idle < (total * cpu_running_mark) / 100 && + curfreq < freqs[0]) { + i -= 2; + if (i < 0) + i = 0; + if (vflag) { + printf("idle time < %d%%, increasing clock" + " speed from %d MHz to %d MHz\n", + cpu_running_mark, curfreq, freqs[i]); + } + if (set_freq(freqs[i])) + err(1, "error setting CPU frequency %d", freqs[i]); + } else if (idle > (total * cpu_idle_mark) / 100 && + curfreq > freqs[numfreqs - 1]) { + i++; + if (vflag) { + printf("idle time > %d%%, decreasing clock" + " speed from %d MHz to %d MHz\n", + cpu_idle_mark, curfreq, freqs[i]); + } + if (set_freq(freqs[i])) + err(1, "error setting CPU frequency %d", freqs[i]); + } + continue; + } + /* * If we're idle less than the active mark, jump the CPU to * its fastest speed if we're not there yet. If we're idle -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:29:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 241A216A4CE for ; Mon, 18 Apr 2005 12:29:23 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D38543D45 for ; Mon, 18 Apr 2005 12:29:22 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3ICTLqj056046; Mon, 18 Apr 2005 07:29:21 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4263A7F7.3060707@centtech.com> Date: Mon, 18 Apr 2005 07:28:39 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <2304.1113826754@critter.freebsd.dk> In-Reply-To: <2304.1113826754@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/837/Sun Apr 17 10:25:32 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:29:23 -0000 Poul-Henning Kamp wrote: > In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: > >>Lukas Ertl wrote: >> >>There's been some discussion on the -mobile list (I believe) about >>this kind of thing before. I think powerd is currently running with >>a 'best shot' configuration, and I'm pretty sure that if anyone has >>a better algorithm in a patch form for people to try, I'm certain the >>good people with commit bits would easily commit a patched better version. > > > I don't think a proportional approach will work in this case, the steps > are too far apart. > > I also think the switch to full speed is wrong. Such see-saw > algorithms waste far too much time decaying. A less steep flank > should be used. > > For instance: > > if (idle > 90%) > reduce clock one step. > if (idle < 80%) > increase clock two steps. > Mostly what I see on my laptop when it is 'idle' (meaning I'm in X, with my mail client running, window manager, etc, but not actively using anything (not even moving the mouse)), is the speed dropping down to 100Mhz (going through about 5 steps, ~ half the speed each step), then shooting back to 100% speed. This ends up looking like a sawtooth, so it wastes lots of energy on the fall back to 100Mhz. I essentially end up with an average of the mid-way point between max speed and lowest speed (1.8GHz and 100MHz for me), which of course isn't ideal. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:30:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B708016A4CE; Mon, 18 Apr 2005 12:30:15 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02BF243D49; Mon, 18 Apr 2005 12:30:15 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3ICUEQ1056061; Mon, 18 Apr 2005 07:30:14 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4263A82B.2080309@centtech.com> Date: Mon, 18 Apr 2005 07:29:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <4262B185.7080100@centtech.com> <426329E6.4090105@root.org> In-Reply-To: <426329E6.4090105@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/837/Sun Apr 17 10:25:32 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:30:15 -0000 Nate Lawson wrote: > Eric Anderson wrote: > >> Mark Santcroos wrote: >> >>> On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: >>> >>>> looks like acopcode.h and acnames.h are not included in the patch. >>> >>> >>> >>> >>> Oops, rusty cvs skills :) >>> >>> The following files have been added to the diff: >>> abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c >>> aemain.c osunixdir.c >>> >>> Same location, more fun: >>> http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz >> >> >> >> I just applied this patch, and everything seems to run ok. >> >> Only thing I noticed was that I get pauses now about every 6 seconds. >> All my recent dmesg/sysctl/etc output is here: >> >> http://googlebit.com/freebsd/ >> >> Eric > > > Is there any difference in the embedded controller? You have to boot > without -v to see its messages (they scrolled in your output). Any new > warning messages when you get the pause? > I'm not sure at this point - I've booted without -v now (dmesg on the site above), and I'll rebuild without the new patches if that's helpful. More information: I don't see the pause anywhere on bootup, and at the console everything seems fine, with no pauses. However, once I am in X-Windows (using Xorg), I then see the pause. I'll try to start up in no-window manager mode to remove that from the mix. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:34:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D7C916A4CE for ; Mon, 18 Apr 2005 12:34:25 +0000 (GMT) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1953B43D2D for ; Mon, 18 Apr 2005 12:34:24 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: from hadriel.linnet (wll192-81.wlan.hu-berlin.de [141.20.192.81]) (authenticated bits=0) (8.12.10/8.12.9/INF-2.0-MA-SOLARIS-2.8) with ESMTP id j3ICYJGR011517 for ; Mon, 18 Apr 2005 14:34:23 +0200 (MEST) Date: Mon, 18 Apr 2005 14:34:13 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20050418143413.058b0598.sebastian.ssmoller@gmx.net> In-Reply-To: <2304.1113826754@critter.freebsd.dk> References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:34:25 -0000 > > I don't think a proportional approach will work in this case, the steps > are too far apart. > > I also think the switch to full speed is wrong. Such see-saw > algorithms waste far too much time decaying. A less steep flank > should be used. what about just taking the algo from estctrl? i dont know what algo exactly it implements but it worked very well for me ... regards, seb From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 12:35:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D7F916A4CE for ; Mon, 18 Apr 2005 12:35:31 +0000 (GMT) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3785243D1F for ; Mon, 18 Apr 2005 12:35:30 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: from hadriel.linnet (wll192-81.wlan.hu-berlin.de [141.20.192.81]) (authenticated bits=0) (8.12.10/8.12.9/INF-2.0-MA-SOLARIS-2.8) with ESMTP id j3ICZTGR011666 for ; Mon, 18 Apr 2005 14:35:29 +0200 (MEST) Date: Mon, 18 Apr 2005 14:35:23 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20050418143523.3d935084.sebastian.ssmoller@gmx.net> In-Reply-To: <2428.1113827273@critter.freebsd.dk> References: <2304.1113826754@critter.freebsd.dk> <2428.1113827273@critter.freebsd.dk> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 12:35:31 -0000 wow - that was fast ;-) thx - i'll give it a try today and i'll let u know how it works thx regards, seb On Mon, 18 Apr 2005 14:27:53 +0200 "Poul-Henning Kamp" wrote: > > Here's a patch which implements "phk" mode: > > > Index: powerd.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/powerd/powerd.c,v > retrieving revision 1.4 > diff -u -r1.4 powerd.c > --- powerd.c 27 Feb 2005 01:58:49 -0000 1.4 > +++ powerd.c 18 Apr 2005 12:26:03 -0000 > @@ -50,6 +50,7 @@ > enum modes_t { > MODE_MIN, > MODE_ADAPTIVE, > + MODE_PHK, > MODE_MAX, > }; > > @@ -220,6 +221,8 @@ > *mode = MODE_MAX; > else if (strcmp(arg, "adaptive") == 0) > *mode = MODE_ADAPTIVE; > + else if (strcmp(arg, "phk") == 0) > + *mode = MODE_PHK; > else > errx(1, "bad option: -%c %s", (char)ch, optarg); > } > @@ -377,6 +380,37 @@ > if (read_usage_times(&idle, &total)) > err(1, "read_usage_times"); > > + if (mode == MODE_PHK) { > + for (i = 0; i < numfreqs - 1; i++) { > + if (freqs[i] == curfreq) > + break; > + } > + if (idle < (total * cpu_running_mark) / 100 && > + curfreq < freqs[0]) { > + i -= 2; > + if (i < 0) > + i = 0; > + if (vflag) { > + printf("idle time < %d%%, increasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_running_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } else if (idle > (total * cpu_idle_mark) / 100 && > + curfreq > freqs[numfreqs - 1]) { > + i++; > + if (vflag) { > + printf("idle time > %d%%, decreasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_idle_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } > + continue; > + } > + > /* > * If we're idle less than the active mark, jump the CPU to > * its fastest speed if we're not there yet. If we're idle > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 13:37:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D45D16A4CE for ; Mon, 18 Apr 2005 13:37:48 +0000 (GMT) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C389343D31 for ; Mon, 18 Apr 2005 13:37:43 +0000 (GMT) (envelope-from svein-freebsd-current@theloosingend.net) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 732757F12 for ; Mon, 18 Apr 2005 15:37:42 +0200 (CEST) Received: from maren.thelosingend.net (maren.math.ntnu.no [129.241.211.48]) by fri.itea.ntnu.no (Postfix) with SMTP for ; Mon, 18 Apr 2005 15:37:42 +0200 (CEST) Received: (qmail 25499 invoked by uid 1001); 18 Apr 2005 13:37:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2005 13:37:25 -0000 Date: Mon, 18 Apr 2005 15:37:25 +0200 (CEST) From: Svein Halvor Halvorsen X-X-Sender: sveinhal@maren.thelosingend.net To: sebastian ssmoller In-Reply-To: <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> Message-ID: <20050418153617.I24989@maren.thelosingend.net> References: <20050416213144.9A08C7306E@freebsd-current.sentex.ca> <20050418134818.62d172f2.sebastian.ssmoller@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 13:37:48 -0000 * sebastian ssmoller [2005-04-18 13:48 +0200] > the currently implemented strategy caused the fan of my notebook to switch > on within 15 min which it never did with estctrl running :( ... Agreed! This is exactly why I don't use powerd, and use estctrl instead. From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 14:01:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62BD016A4CE for ; Mon, 18 Apr 2005 14:01:28 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9867443D5C for ; Mon, 18 Apr 2005 14:01:27 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DNWoP-00082N-00; Mon, 18 Apr 2005 16:01:17 +0200 Date: Mon, 18 Apr 2005 16:01:17 +0200 To: Poul-Henning Kamp Message-ID: <20050418140117.GH2298@poupinou.org> References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2304.1113826754@critter.freebsd.dk> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 14:01:28 -0000 On Mon, Apr 18, 2005 at 02:19:14PM +0200, Poul-Henning Kamp wrote: > In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: > >Lukas Ertl wrote: > > > >There's been some discussion on the -mobile list (I believe) about > >this kind of thing before. I think powerd is currently running with > >a 'best shot' configuration, and I'm pretty sure that if anyone has > >a better algorithm in a patch form for people to try, I'm certain the > >good people with commit bits would easily commit a patched better version. > > I don't think a proportional approach will work in this case, the steps > are too far apart. > > I also think the switch to full speed is wrong. Such see-saw > algorithms waste far too much time decaying. A less steep flank > should be used. The full speed thing is right in almost case. When we ran the processor at lower speed, then we loose somehow the runpercent if running at full speed at previous window. Suppose for example we have those normalized performance states: 100% 66% 50% If we ran at 50% but read a 100% runpercent, then if we were running at full speed, we would got a 50% runpercent which is given by (runpercent * normalized_speed). Those far, we can only say actually that runpercent (at full speed) is in-between 50% and 100%. If, for example, the real runpercent (at full speed) is actually 50%, then we should stay at 50%, if its at 66%, we should set speed at 66% and so on. But we can only estimate a value of 50% in all cases. Therefore almost all algorithms will put the processor at full speed if an increase is detected. This work pretty well when the polling intervall is small (something between 40 or 50 milliseconds). In the case of powerd, the real trouble is maybe the polling interval and we should use an adaptive filter in order to fix this issue. The case when we detect to go down is less problematic because we are able to compute at least an accurate estimation of runpercent for the previous window. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 14:40:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698EF16A4CE for ; Mon, 18 Apr 2005 14:40:50 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5357043D2F for ; Mon, 18 Apr 2005 14:40:49 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3IEemA9024310; Mon, 18 Apr 2005 09:40:48 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4263C6C5.300@centtech.com> Date: Mon, 18 Apr 2005 09:40:05 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Ducrot References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> <20050418140117.GH2298@poupinou.org> In-Reply-To: <20050418140117.GH2298@poupinou.org> Content-Type: multipart/mixed; boundary="------------020006060009000008010300" cc: Poul-Henning Kamp cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 14:40:50 -0000 This is a multi-part message in MIME format. --------------020006060009000008010300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruno Ducrot wrote: > On Mon, Apr 18, 2005 at 02:19:14PM +0200, Poul-Henning Kamp wrote: > >>In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: >> >>>Lukas Ertl wrote: >>> >>>There's been some discussion on the -mobile list (I believe) about >>>this kind of thing before. I think powerd is currently running with >>>a 'best shot' configuration, and I'm pretty sure that if anyone has >>>a better algorithm in a patch form for people to try, I'm certain the >>>good people with commit bits would easily commit a patched better version. >> >>I don't think a proportional approach will work in this case, the steps >>are too far apart. >> >>I also think the switch to full speed is wrong. Such see-saw >>algorithms waste far too much time decaying. A less steep flank >>should be used. > > > The full speed thing is right in almost case. When we ran the processor > at lower speed, then we loose somehow the runpercent if running > at full speed at previous window. > Suppose for example we have those normalized performance > states: 100% 66% 50% > If we ran at 50% but read a 100% runpercent, then if we were running > at full speed, we would got a 50% runpercent which is given by > (runpercent * normalized_speed). Those far, we can only say actually > that runpercent (at full speed) is in-between 50% and 100%. If, for > example, the real runpercent (at full speed) is actually 50%, > then we should stay at 50%, if its at 66%, we should set speed at 66% > and so on. But we can only estimate a value of 50% in all cases. > > Therefore almost all algorithms will put the processor at full speed > if an increase is detected. > This work pretty well when the polling intervall is small > (something between 40 or 50 milliseconds). > In the case of powerd, the real trouble is maybe the polling interval > and we should use an adaptive filter in order to fix this issue. > > The case when we detect to go down is less problematic because we are > able to compute at least an accurate estimation of runpercent for > the previous window. > Ok, I've attached my tweaks to PHK's adaptive. I run it like this: /usr/sbin/powerd -a max -b adaptive2 -p 100 -r 20 Seems to do a pretty decent job at being responsive, yet gives me a longer battery time than the default adaptive. Not perfect, but still better I think.. (Thanks PHK for a quick patch!) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ --------------020006060009000008010300 Content-Type: text/plain; name="powerd.c-patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="powerd.c-patch" --- powerd.c Mon Apr 18 09:26:49 2005 +++ powerd.c-new Mon Apr 18 09:18:30 2005 @@ -26,7 +26,7 @@ */ #include -__FBSDID("$FreeBSD: /repoman/r/ncvs/src/usr.sbin/powerd/powerd.c,v 1.6 2005/04/10 20:42:55 njl Exp $"); +__FBSDID("$FreeBSD: src/usr.sbin/powerd/powerd.c,v 1.6 2005/04/10 20:42:55 njl Exp $"); #include #include @@ -51,6 +51,7 @@ enum modes_t { MODE_MIN, MODE_ADAPTIVE, + MODE_ADAPTIVE2, MODE_MAX, }; @@ -229,6 +230,8 @@ *mode = MODE_MAX; else if (strcmp(arg, "adaptive") == 0) *mode = MODE_ADAPTIVE; + else if (strcmp(arg, "adaptive2") == 0) + *mode = MODE_ADAPTIVE2; else errx(1, "bad option: -%c %s", (char)ch, optarg); } @@ -416,6 +419,44 @@ /* Adaptive mode; get the current CPU usage times. */ if (read_usage_times(&idle, &total)) err(1, "read_usage_times"); + + if (mode == MODE_ADAPTIVE2) { + for (i = 0; i < numfreqs - 1; i++) { + if (freqs[i] == curfreq) + break; + } + if (idle < (total * cpu_running_mark) / 100 && + curfreq < freqs[0]) { + i -= 4; + if (i < 0) + i = 0; + if (vflag) { + printf("idle time < %d%%, increasing clock" + " speed from %d MHz to %d MHz\n", + cpu_running_mark, curfreq, freqs[i]); + } + if (set_freq(freqs[i])) + err(1, "error setting CPU frequency %d", freqs[i]); + + } else if (idle > (total * cpu_idle_mark) / 100 && + curfreq > freqs[numfreqs - 1]) { + i++; + i++; + i++; + if (vflag) { + printf("idle time > %d%%, decreasing clock" + " speed from %d MHz to %d MHz\n", + cpu_idle_mark, curfreq, freqs[i]); + } + if (set_freq(freqs[i])) + err(1, "error setting CPU frequency %d", freqs[i]); + usleep(poll_ival); + } else if (curfreq == freqs[0]) { + usleep(poll_ival); + usleep(poll_ival); + } + continue; + } /* * If we're idle less than the active mark, jump the CPU to --------------020006060009000008010300-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 16:00:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 540BF16A4CE for ; Mon, 18 Apr 2005 16:00:24 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D4643D5A for ; Mon, 18 Apr 2005 16:00:24 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Mon, 18 Apr 2005 09:00:23 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2C3C05D08; Mon, 18 Apr 2005 09:00:22 -0700 (PDT) To: Randy Bush In-reply-to: Your message of "Sat, 16 Apr 2005 08:03:09 -1000." <16993.21341.792720.225462@roam.psg.com> Date: Mon, 18 Apr 2005 09:00:22 -0700 From: "Kevin Oberman" Message-Id: <20050418160022.2C3C05D08@ptavv.es.net> cc: current@freebsd.org Subject: Re: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 16:00:24 -0000 > From: Randy Bush > Date: Sat, 16 Apr 2005 08:03:09 -1000 > > kevin, what was the last cvsup date which gave you a workable current > on your thinkpad. i will revert to it and see if it addresses the > inability to start my window system on a t41 Randy, I thought I knew the answer to this, but decided to confirm it before replying. Good thing! I can state without a doubt that it worked on Mar. 31 with the Scott's ATAPICAM patches. (They were not committed until late on 4/5.) The failure certainly did show up by 4/8. I am currently building a system at 4/5 just after the last ATAPICAM patch of the day was committed. Doug, ktrace on the hung process shows nothing. Other than context switches, there are no kernel events that appear to originate from gkrellm. Since the problem can take hours to show up, starting ktrace and waiting to see what has been captured may take a while and fill a LOT of disk. If I can get a better handle on just when it happened, I may try to fill a backup disk with ktrace data and see if I can find anything. Two notes: I am running ULE on the system and it seems like it might tend to happen when the CPU is throttled back to about 300 MHz by TCC and ST. (This is just conjecture at this point.) I have only had X freeze on initialization once. What Randy is seeing my be a totally separate problem from what I am seeing with gkrellm (or not). Still hunting. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 16:02:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B12A16A4CE for ; Mon, 18 Apr 2005 16:02:28 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA94743D45 for ; Mon, 18 Apr 2005 16:02:27 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNYhd-00089Z-2S for current@freebsd.org; Mon, 18 Apr 2005 18:02:27 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3IG2PiO000810 for ; Mon, 18 Apr 2005 18:02:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Mon, 18 Apr 2005 18:02:25 +0200 Message-ID: <809.1113840145@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Synaptics support and suspend ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 16:02:28 -0000 On my T41p suspend (or rather: resume) does not work if I have enabled synaptics support in the psm driver. There is a t least one problem I can see: the sysctls are re-registered, but I don't know if that is the main problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 18:51:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94F7816A4CE for ; Mon, 18 Apr 2005 18:51:49 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4139943D46 for ; Mon, 18 Apr 2005 18:51:49 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3IIpm0p018471 for ; Mon, 18 Apr 2005 11:51:48 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3IIpmeA018470 for current@freebsd.org; Mon, 18 Apr 2005 11:51:48 -0700 Date: Mon, 18 Apr 2005 11:51:48 -0700 From: Brooks Davis To: current@freebsd.org Message-ID: <20050418185148.GA15795@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 18:51:49 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've just committed support for IPv6 to IPFW. Various versions of the pack have been in use for some time, but it's a large change so be careful. IP6FW should be considered deprecated. It may or may not appear in 6.0 (subject to user feedback and discussions with re@). It may be possible to MFC this change given sufficient user interest. I have made no decision on this at this time. -- Brooks ----- Forwarded message from Brooks Davis ----- From: Brooks Davis Date: Mon, 18 Apr 2005 18:35:05 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sbin/ipfw ipfw.8 ipfw2.c src/sys/netinet ip_dummynet.c ip_dummynet.h ip_fw.h ip_fw2.c ip_fw_pfil.c src/sys/netinet6 ip6_output.c brooks 2005-04-18 18:35:05 UTC FreeBSD src repository Modified files: sbin/ipfw ipfw.8 ipfw2.c=20 sys/netinet ip_dummynet.c ip_dummynet.h ip_fw.h=20 ip_fw2.c ip_fw_pfil.c=20 sys/netinet6 ip6_output.c=20 Log: Add IPv6 support to IPFW and Dummynet. =20 Submitted by: Mariano Tortoriello and Raffaele De Lorenzo (via luigi) =20 Revision Changes Path 1.168 +122 -30 src/sbin/ipfw/ipfw.8 1.71 +698 -35 src/sbin/ipfw/ipfw2.c 1.90 +69 -14 src/sys/netinet/ip_dummynet.c 1.35 +3 -0 src/sys/netinet/ip_dummynet.h 1.98 +67 -0 src/sys/netinet/ip_fw.h 1.93 +333 -32 src/sys/netinet/ip_fw2.c 1.19 +33 -2 src/sys/netinet/ip_fw_pfil.c 1.88 +26 -0 src/sys/netinet6/ip6_output.c ----- End forwarded message ----- --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCZAHEXY6L6fI4GtQRAoFhAKDkluxXmBR0g0B3kgre2C3LvGoOgwCfT9j0 ybcXhcCGl0G9TTCCIazpUgc= =zzco -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 19:36:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4261516A4CE; Mon, 18 Apr 2005 19:36:19 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6E6943D45; Mon, 18 Apr 2005 19:36:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j3IJaGLS018278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Apr 2005 12:36:18 -0700 Message-ID: <42640C2B.20100@root.org> Date: Mon, 18 Apr 2005 12:36:11 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Brand References: <20050417205230.GC837@chimie.u-strasbg.fr> <4263E9BF.4050501@root.org> <20050418192235.GA867@chimie.u-strasbg.fr> In-Reply-To: <20050418192235.GA867@chimie.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: hw.acpi.battery.life alway at 100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 19:36:19 -0000 Guy Brand wrote: > On 18 avril at 10:09, Nate Lawson wrote: >>> hw.acpi.battery.time: 94 >> >>You'll have to do more investigating. There were no MFCs that I can see >>to acpi between those two dates. First, compare the output of dmesg >>between the working and non-working kernels and see if anything has changed. > > OK. So as shown only hw.acpi.battery.life is wrong in sysctl output. > An other symptom is related to this problem: just after a boot the > system is weird, the keyboard is reactive (changing ttyv ok, typing > commands ok) but answers to commands are very very slow. This > strange state lasts around 5 minutes during which > > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > > after this delay, the logs shows a line: > > acpi_cmbat0: battery initialization done, tried 1 times > > and the system is responsive as usual, but the life status is wrong > (sticked to 100) as written in my previous mail. > > I diffed the dmesg outputs, here is it: > > --- mm-prerelease Mon Apr 18 21:14:47 2005 > +++ mm-stable Mon Apr 18 21:17:07 2005 > @@ -587,3 +586,9 @@ > kernel: Mounting root from ufs:/dev/ad0s1a > kernel: start_init: trying /sbin/init > kernel: splash: image decoder found: logo_saver > +kernel: acpi_ec0: info: new max delay is 610 us > +kernel: acpi_ec0: info: new max delay is 630 us > +kernel: acpi_ec0: info: new max delay is 820 us > +kernel: acpi_cmbat0: battery initialization failed, giving up > +kernel: acpi_ec0: info: new max delay is 930 us Ok, the EC delays are the likely culprit. The battery driver is not getting a response from the EC and so you get no battery info. I'm adding -current to the CC since a change elsewhere in the kernel may have triggered this. Is anyone aware why it appears interrupts are now disabled for a while just after launching init? The change appeared in 5-STABLE between March 17 and April 17. Guy, can you try disabling usb? Also, can you cvsup to dates between March 17 and April 17 to try to narrow down the exact date this started occurring? -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 20:06:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D1D16A4CE; Mon, 18 Apr 2005 20:06:28 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0704443D53; Mon, 18 Apr 2005 20:06:27 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3IK6Qkj027367; Mon, 18 Apr 2005 15:06:26 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42641316.9000405@centtech.com> Date: Mon, 18 Apr 2005 15:05:42 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <4262B185.7080100@centtech.com> <426329E6.4090105@root.org> In-Reply-To: <426329E6.4090105@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 20:06:28 -0000 Nate Lawson wrote: > Eric Anderson wrote: > >> Mark Santcroos wrote: >> >>> On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: >>> >>>> looks like acopcode.h and acnames.h are not included in the patch. >>> >>> >>> >>> >>> Oops, rusty cvs skills :) >>> >>> The following files have been added to the diff: >>> abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c >>> aemain.c osunixdir.c >>> >>> Same location, more fun: >>> http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz >> >> >> >> I just applied this patch, and everything seems to run ok. >> >> Only thing I noticed was that I get pauses now about every 6 seconds. >> All my recent dmesg/sysctl/etc output is here: >> >> http://googlebit.com/freebsd/ >> >> Eric > > > Is there any difference in the embedded controller? You have to boot > without -v to see its messages (they scrolled in your output). Any new > warning messages when you get the pause? > It is apparently something in xfce4's battery monitoring plugin. It hasn't been upgraded or changed since the ACPI changes. Is there something I can do to see what causes it to choke my machine? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 21:30:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B34416A4CE for ; Mon, 18 Apr 2005 21:30:30 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E30E43D3F for ; Mon, 18 Apr 2005 21:30:29 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IF500G0QVRH6S@nemesis.sorbs.net> for freebsd-current@freebsd.org; Tue, 19 Apr 2005 07:30:54 +1000 (EST) Date: Tue, 19 Apr 2005 07:29:18 +1000 From: Matthew Sullivan To: freebsd-current@freebsd.org Message-id: <426426AE.2060406@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050808020208060303070103; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 Subject: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 21:30:30 -0000 This is a cryptographically signed message in MIME format. --------------ms050808020208060303070103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Any reason why FreeBSD 5.2.1+ and 5.3-p9 set DF on all packets? I'm getting some real problems with VPNs, setting the interface MTU to 1024 fixes them, but it really is less than ideal. example with dominator [203.15.51.36] MTU at 1500, vpn server is at 203.15.51.36 (all interfaces are MTU 1500 except gif0 which is 1280), other end of the VPN has interfaces at MTU 1500 which serices the 10.200.254.0 network (wireless).... root@dominator:~# tcpdump -n | grep 10.200.254.98 tcpdump: listening on bge0 23:36:22.638202 10.200.254.98.33118 > 203.15.51.36.24: SWE 742813284:742813284(0) win 5840 (DF) 23:36:22.638259 203.15.51.36.24 > 10.200.254.98.33118: S 2275901409:2275901409(0) ack 742813285 win 65535 (DF) 23:36:22.680880 10.200.254.98.33118 > 203.15.51.36.24: . ack 1 win 5840 (DF) 23:36:22.683004 203.15.51.36.24 > 10.200.254.98.33118: P 1:43(42) ack 1 win 33304 (DF) 23:36:22.728581 10.200.254.98.33118 > 203.15.51.36.24: . ack 43 win 5840 (DF) . . . 23:36:23.474807 203.15.51.36.24 > 10.200.254.98.33118: P 2075:2171(96) ack 2425 win 33304 (DF) 23:36:23.475751 10.200.254.98.33118 > 203.15.51.36.24: P 2425:2537(112) ack 2075 win 10496 (DF) [tos 0x10] 23:36:23.510998 203.15.51.36.24 > 10.200.254.98.33118: P 2171:2219(48) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.511752 203.15.51.36.24 > 10.200.254.98.33118: P 2219:2315(96) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.514316 203.15.51.36.24 > 10.200.254.98.33118: P 2315:3643(1328) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.515060 203.15.51.61 > 203.15.51.36: icmp: 10.200.254.98 unreachable - need to frag (DF) 23:36:23.516599 203.15.51.36.24 > 10.200.254.98.33118: P 3643:3723(80) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.517255 203.15.51.36.24 > 10.200.254.98.33118: P 3723:3771(48) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.517337 203.15.51.36.24 > 10.200.254.98.33118: P 3771:3995(224) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.527961 203.15.51.36.24 > 10.200.254.98.33118: P 3995:4059(64) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.552652 10.200.254.98.33118 > 203.15.51.36.24: . ack 2171 win 10496 (DF) [tos 0x10] 23:36:23.561291 10.200.254.98.33118 > 203.15.51.36.24: . ack 2219 win 10496 (DF) [tos 0x10] 23:36:23.565812 10.200.254.98.33118 > 203.15.51.36.24: . ack 2315 win 10496 (DF) [tos 0x10] 23:36:23.570650 10.200.254.98.33118 > 203.15.51.36.24: . ack 2315 win 10496 (DF) [tos 0x10] 23:36:23.577811 10.200.254.98.33118 > 203.15.51.36.24: . ack 2315 win 10496 (DF) [tos 0x10] 23:36:23.577829 10.200.254.98.33118 > 203.15.51.36.24: . ack 2315 win 10496 (DF) [tos 0x10] 23:36:23.577880 203.15.51.36.24 > 10.200.254.98.33118: . 2315:3763(1448) ack 2537 win 33304 (DF) [tos 0x10] 23:36:23.578406 203.15.51.61 > 203.15.51.36: icmp: 10.200.254.98 unreachable - need to frag (DF) 23:36:23.582784 10.200.254.98.33118 > 203.15.51.36.24: . ack 2315 win -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms050808020208060303070103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQxODIxMjkxOFowIwYJKoZIhvcNAQkEMRYEFAVwY8BJP11yEBSt VgKrvVBKSUwkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQIYILpGxMxATXZmyqCzzm0NLNJq9y8xBIpGlnM0vo1F/m9B5FQs3cK+iadV33+r3/XX7 In4WZySF2HDIh0Rk0FYAAAAAAAA= --------------ms050808020208060303070103-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 22:31:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CE316A4CE for ; Mon, 18 Apr 2005 22:31:16 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B09A243D1F for ; Mon, 18 Apr 2005 22:31:16 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DNelw-0006P4-2d; Mon, 18 Apr 2005 22:31:16 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DNelr-0000KS-JQ; Mon, 18 Apr 2005 12:31:11 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.13614.992375.433212@roam.psg.com> Date: Mon, 18 Apr 2005 12:31:10 -1000 To: "Kevin Oberman" References: <16993.21341.792720.225462@roam.psg.com> <20050418160022.2C3C05D08@ptavv.es.net> cc: current@freebsd.org Subject: Re: Weird display problem in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 22:31:17 -0000 > I can state without a doubt that it worked on Mar. 31 with the Scott's > ATAPICAM patches. (They were not committed until late on 4/5.) The > failure certainly did show up by 4/8. I am currently building a system > at 4/5 just after the last ATAPICAM patch of the day was committed. i just built with *default date=2005.04.06.06.06.06 and o X and gnome work o resume locks up doing disk access o pcmcia (or whatever the newfangled name is:-) works randy From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 23:29:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8148816A4CE for ; Mon, 18 Apr 2005 23:29:45 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0587443D5C for ; Mon, 18 Apr 2005 23:29:45 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 18 Apr 2005 16:29:43 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 271AD5D07; Mon, 18 Apr 2005 16:29:44 -0700 (PDT) To: "Poul-Henning Kamp" In-reply-to: Your message of "Mon, 18 Apr 2005 14:27:53 +0200." <2428.1113827273@critter.freebsd.dk> Date: Mon, 18 Apr 2005 16:29:44 -0700 From: "Kevin Oberman" Message-Id: <20050418232944.271AD5D07@ptavv.es.net> cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 23:29:45 -0000 > From: "Poul-Henning Kamp" > Date: Mon, 18 Apr 2005 14:27:53 +0200 > Sender: owner-freebsd-current@freebsd.org > > In message <2304.1113826754@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > >In message <4263A33A.3030201@centtech.com>, Eric Anderson writes: > >>Lukas Ertl wrote: > >> > >>There's been some discussion on the -mobile list (I believe) about > >>this kind of thing before. I think powerd is currently running with > >>a 'best shot' configuration, and I'm pretty sure that if anyone has > >>a better algorithm in a patch form for people to try, I'm certain the > >>good people with commit bits would easily commit a patched better version. > > > >I don't think a proportional approach will work in this case, the steps > >are too far apart. > > > >I also think the switch to full speed is wrong. Such see-saw > >algorithms waste far too much time decaying. A less steep flank > >should be used. > > > >For instance: > > > > if (idle > 90%) > > reduce clock one step. > > if (idle < 80%) > > increase clock two steps. > > Here's a patch which implements "phk" mode: > > > Index: powerd.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/powerd/powerd.c,v > retrieving revision 1.4 > diff -u -r1.4 powerd.c > --- powerd.c 27 Feb 2005 01:58:49 -0000 1.4 > +++ powerd.c 18 Apr 2005 12:26:03 -0000 > @@ -50,6 +50,7 @@ > enum modes_t { > MODE_MIN, > MODE_ADAPTIVE, > + MODE_PHK, > MODE_MAX, > }; > > @@ -220,6 +221,8 @@ > *mode = MODE_MAX; > else if (strcmp(arg, "adaptive") == 0) > *mode = MODE_ADAPTIVE; > + else if (strcmp(arg, "phk") == 0) > + *mode = MODE_PHK; > else > errx(1, "bad option: -%c %s", (char)ch, optarg); > } > @@ -377,6 +380,37 @@ > if (read_usage_times(&idle, &total)) > err(1, "read_usage_times"); > > + if (mode == MODE_PHK) { > + for (i = 0; i < numfreqs - 1; i++) { > + if (freqs[i] == curfreq) > + break; > + } > + if (idle < (total * cpu_running_mark) / 100 && > + curfreq < freqs[0]) { > + i -= 2; > + if (i < 0) > + i = 0; > + if (vflag) { > + printf("idle time < %d%%, increasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_running_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } else if (idle > (total * cpu_idle_mark) / 100 && > + curfreq > freqs[numfreqs - 1]) { > + i++; > + if (vflag) { > + printf("idle time > %d%%, decreasing clock" > + " speed from %d MHz to %d MHz\n", > + cpu_idle_mark, curfreq, freqs[i]); > + } > + if (set_freq(freqs[i])) > + err(1, "error setting CPU frequency %d", freqs[i]); > + } > + continue; > + } > + > /* > * If we're idle less than the active mark, jump the CPU to > * its fastest speed if we're not there yet. If we're idle Virtually identical in function to the code I posted to acpi@ when powerd first was added to current, except that it is better written than mine was. Thanks, PHK. I also have found that changing the polling interval to 150 is an improvement. Half a second is just too long, IMHO. I also discovered that with my system (P4M) that some settings can use substantially more power than faster settings, so I have kludged an ugly hack to avoid those settings. These changes make a significant difference in power consumption. Unfortunately my day job has had me too busy to do much work on it of late. I'm on vacation next week and will a) get a lot of time to play with it or b) not touch it because my wife gets annoyed by my spending vacation on a computer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 00:57:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FB3816A4CE for ; Tue, 19 Apr 2005 00:57:28 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7314143D2F for ; Tue, 19 Apr 2005 00:57:27 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3J0v1cY013733; Tue, 19 Apr 2005 10:27:01 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Tue, 19 Apr 2005 10:26:55 +0930 User-Agent: KMail/1.8 References: <20050418232944.271AD5D07@ptavv.es.net> In-Reply-To: <20050418232944.271AD5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20628293.OurAszTEo5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504191026.55803.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Poul-Henning Kamp cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 00:57:28 -0000 --nextPart20628293.OurAszTEo5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 19 Apr 2005 08:59, Kevin Oberman wrote: > I also have found that changing the polling interval to 150 is an > improvement. Half a second is just too long, IMHO. I also discovered > that with my system (P4M) that some settings can use substantially more > power than faster settings, so I have kludged an ugly hack to avoid > those settings. These changes make a significant difference in power > consumption. Can you elaborate on these? It may be worth adding a general algorithm to cull the frequency list power= d=20 uses based on this info. =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 --nextPart20628293.OurAszTEo5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZFdX5ZPcIHs/zowRAj+/AJoC7UkemH2SAsBquRV6j6aikIVzkACeNeSW REcpM92Yo2nytrdztMX2U+g= =VIKz -----END PGP SIGNATURE----- --nextPart20628293.OurAszTEo5-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 01:03:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F272316A4CE for ; Tue, 19 Apr 2005 01:03:10 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C6B43D31 for ; Tue, 19 Apr 2005 01:03:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3J1387E062299; Mon, 18 Apr 2005 20:03:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <426458A1.7010008@centtech.com> Date: Mon, 18 Apr 2005 20:02:25 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <20050418232944.271AD5D07@ptavv.es.net> <200504191026.55803.doconnor@gsoft.com.au> In-Reply-To: <200504191026.55803.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/839/Mon Apr 18 09:53:43 2005 on mh1.centtech.com X-Virus-Status: Clean cc: Poul-Henning Kamp cc: freebsd-current@freebsd.org Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 01:03:11 -0000 Daniel O'Connor wrote: > On Tue, 19 Apr 2005 08:59, Kevin Oberman wrote: > >>I also have found that changing the polling interval to 150 is an >>improvement. Half a second is just too long, IMHO. I also discovered >>that with my system (P4M) that some settings can use substantially more >>power than faster settings, so I have kludged an ugly hack to avoid >>those settings. These changes make a significant difference in power >>consumption. > > > Can you elaborate on these? > It may be worth adding a general algorithm to cull the frequency list powerd > uses based on this info. > Here's a quick perl script that does what I think he was doing. The lines that have "skipping" in it are inefficient. (sorry for the ugly perl) #!/usr/local/bin/perl $sysctl = `sysctl dev.cpu.0.freq_levels`; $sysctl =~ s/.+\: //; @vals = split/\s+/,$sysctl; $lastenergy = 0; foreach $val (@vals) { ($mhz, $energy) = split/\//,$val; $energypermhz = $energy/$mhz; $energypermhz = sprintf ("%0.3f", $energypermhz); if ($lastenergy == 0) { $lastenergy = $energy; } if ($energy > $lastenergy) { print "skipping $energypermhz -> $mhz - $energy\n"; } else { print "$energypermhz -> $mhz - $energy\n"; $lastenergy = $energy; } } -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 04:24:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB8F516A4CE for ; Tue, 19 Apr 2005 04:24:57 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA8D43D46 for ; Tue, 19 Apr 2005 04:24:57 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao02.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050419042454.NOGU6521.lakermmtao02.cox.net@dolphin.local.net>; Tue, 19 Apr 2005 00:24:54 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3J4Ot8q019198; Mon, 18 Apr 2005 23:24:55 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 18 Apr 2005 23:24:55 -0500 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20050418232455.2d530890@dolphin.local.net> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Mathew Kanner Subject: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:24:57 -0000 I've been trying to help Mat Kanner with his yet-to-be-committed MIDI patches, and have run into a perplexing problem on amd64 CURRENT. It seems the "d_maj" member of "struct cdevsw" no longer exists (in sys/sys/conf.h). This is causing Mat's MIDI patches to fail with: > ===> sound/midi (all) > cc -O -pipe -march=athlon64 -Wno-error -D_KERNEL -DKLD_MODULE > -nostdinc -I- -include /usr/obj/usr/src/sys/CUSTOM/opt_global.h -I. > -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g > -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/CUSTOM -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -c > /usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c > /usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c:204: > error: unknown field `d_maj' specified in initializer When was this member removed, and why? And how to work around this? Thanks! -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 04:25:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26E5D16A4CE for ; Tue, 19 Apr 2005 04:25:44 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D10AB43D39 for ; Tue, 19 Apr 2005 04:25:43 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 18 Apr 2005 21:25:43 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 175EC5D07; Mon, 18 Apr 2005 21:25:43 -0700 (PDT) To: "Daniel O'Connor" In-reply-to: Your message of "Tue, 19 Apr 2005 10:26:55 +0930." <200504191026.55803.doconnor@gsoft.com.au> Date: Mon, 18 Apr 2005 21:25:43 -0700 From: "Kevin Oberman" Message-Id: <20050419042543.175EC5D07@ptavv.es.net> cc: Poul-Henning Kamp cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:25:44 -0000 > From: "Daniel O'Connor" > Date: Tue, 19 Apr 2005 10:26:55 +0930 > > --nextPart20628293.OurAszTEo5 > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > On Tue, 19 Apr 2005 08:59, Kevin Oberman wrote: > > I also have found that changing the polling interval to 150 is an > > improvement. Half a second is just too long, IMHO. I also discovered > > that with my system (P4M) that some settings can use substantially more > > power than faster settings, so I have kludged an ugly hack to avoid > > those settings. These changes make a significant difference in power > > consumption. > > Can you elaborate on these? > It may be worth adding a general algorithm to cull the frequency list power> d > uses based on this info. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au You can see the thread in acpi@ archives, but simply states, lower the actual CPU reduces power far more than throttling with TCC. I have two available clock rates (1.8 GHz and 1.2 GHz) and TCC provides 8 evenly spaced steps of 12.5% each. The impact on performance, though, is nearly identical. As a result, if there is a choice between the two, you want to run with the lower frequency nd less throttle, but the current code does it the other way. As a result I am limited to 1800, 1575, 1350, 1200, 1050, 750, 600, 300, and 150. cpu.dev.0.freq Temperature CPU Speed 1800 >_PSV 1800 1575 >_PSV 1800 1350 85 1800 1200 73 1200 1125 82 1800 1050 69 1200 900 77 1800 750 64 1200 675 72 1800 600 62 1200 450 66 1800 300 56 1200 225 61 1800 150 54 1200 Temperature is the steady state CPU temperature when running the CPU at full speed (md5) for 5 minutes. It should be proportional to power consumption. I don't know how well this plays with EST or standard throttling (non-P4TCC) and, since my system does not provide energy numbers (it's not EST), there is no easy way to know how it should run except testing. When I get a little more time, I hope to do some more work on this, but, for now, go with PHK's mods and, if energy numbers are available, base the algorithm on that. -- 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 -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 04:37:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE98F16A4CE; Tue, 19 Apr 2005 04:37:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFCC843D1F; Tue, 19 Apr 2005 04:37:46 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3J4bfus038869; Tue, 19 Apr 2005 04:37:43 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42648B40.6040701@freebsd.org> Date: Tue, 19 Apr 2005 12:38:24 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050214014217.GB85932@wantadilla.lemis.com> <34cb7c8405041717342891f2@mail.gmail.com> In-Reply-To: <34cb7c8405041717342891f2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Greg 'groggy' Lehey cc: FreeBSD Current Subject: Re: Race condition in debugger? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:37:47 -0000 Peter Edwards wrote: >[Very late response: I just experienced the same problem and >remembered the issue had been brought up before] > >On 2/14/05, Greg 'groggy' Lehey wrote: > > >>I'm having some problems with userland gdb on recent -CURRENT builds: >>at some point it hangs. >> >>Specifically, I'm setting a conditional breakpoint like this: >> >> b Minsert_blockletpointer if I->inode_num == 0x1f0bb >> >>inode_num increments for 1, so I hit this breakpoint about 100,000 >>times. Or I should. What happens is that the debugger hangs at some >>point on the way. ktrace shows multiple copies of: >> >> 12325 gdb CALL ptrace(12,0x3026,0xbfbfd5e0,0) >> 12325 gdb RET ptrace 0 >> 12325 gdb CALL ptrace(PT_STEP,0x3026,0x1,0) >> 12325 gdb RET ptrace 0 >> 12325 gdb CALL wait4(0xffffffff,0xbfbfd808,0,0) <-- stops here >> 12325 gdb RET wait4 12326/0x3026 >> 12325 gdb CALL kill(0x3026,0) >> 12325 gdb RET kill 0 >> 12325 gdb CALL ptrace(PT_GETREGS,0x3026,0xbfbfd5c0,0) >> >>When it hangs, it's at the call to wait4, as shown. It looks like the >>completion of the ptrace request isn't being reported back. >> >> > >I think I know what's going on with this, and I have a feeling that >there's a couple of other wait()-related issues that were left open on >the lists that might be explained by the issue. > >Here's my hypothesis: kern_wait() checks each child of the current >process to see if they have exited, or should otherwise report status >to wait/wait3/wait4/waitpid, If it finds that all candidate children >have nothing to report, it goes asleep, waiting to be awoken by the/a >child reporting status, and repeats the process: it looks a bit like >this: > >kern_wait() >{ >loop: > foreach child of self { > if (child has status to report) > return status; > } > lock self > msleep(on "self") > unlock self > goto loop; >} > >Problem is, that there's no lock protecting that the conditions in the >inner loop hold by the time the current process locks its own "struct >proc" and invokes msleep(). (It's probably most likely the race will >happen on an SMP machine or with PREEMPTION, but the aquiry of >curproc's lock could possibly cause the issue if it needed to sleep.), >i.e., you can miss the wakeup generated by a particular child between >checking the process in the inner loop, and going to sleep. > >I can at least reproduce this for the ptrace/gdb case, but AFAICT, it >could happen for the standard wait()/exit() path, too. I worked up a >patch to fix the problem by having those parts of the kernel that wake >the process up flag the fact in the parent's flags and doing the >wakeup while holding tha parent process lock, and noticing if this >flag has been set before sleeping. (A simpler solution would be to >hold the parent lock across the bulk of kern_wait, but from what I can >gather this will lead to at least one LOR) > >I've been unable to reproduce the problem with a kernel with this >patch, and using a nice sprinkling of printfs can show that when GDB >hangs, the race has just occurred. > >Anyone got opinions on this? >Cheers, >Peadar. > > I just found another case that if the parent masks SIGCHLD, then we will get the race too. I have tested the patch, it works, I will tweak the patch and commit it soon. David Xu From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 04:45:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E1A816A4CE for ; Tue, 19 Apr 2005 04:45:52 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3322B43D31 for ; Tue, 19 Apr 2005 04:45:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3J4llZY079027; Mon, 18 Apr 2005 22:47:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42648C95.3010102@samsco.org> Date: Mon, 18 Apr 2005 22:44:05 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Conrad J. Sabatier" References: <20050418232455.2d530890@dolphin.local.net> In-Reply-To: <20050418232455.2d530890@dolphin.local.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:45:52 -0000 Conrad J. Sabatier wrote: > I've been trying to help Mat Kanner with his yet-to-be-committed MIDI > patches, and have run into a perplexing problem on amd64 CURRENT. It > seems the "d_maj" member of "struct cdevsw" no longer exists (in > sys/sys/conf.h). This is causing Mat's MIDI patches to fail with: > > > >>===> sound/midi (all) >>cc -O -pipe -march=athlon64 -Wno-error -D_KERNEL -DKLD_MODULE >>-nostdinc -I- -include /usr/obj/usr/src/sys/CUSTOM/opt_global.h -I. >>-I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g >>-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/CUSTOM -mcmodel=kernel >>-mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow >>-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall >>-Wredundant-decls -Wnested-externs -Wstrict-prototypes >>-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>-fformat-extensions -std=c99 -c >>/usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c >>/usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c:204: >>error: unknown field `d_maj' specified in initializer > > > When was this member removed, and why? And how to work around this? > > Thanks! > Major numbers are now dynamically assigned. The shims for allowing drivers to choose a static major number were removed a few months ago. There is no work-around for this; just don't include the field anymore in 6-current sources. If there is something that thinks it needs explicit knowledge of major numbers, let me know and we can discuss how to fix it. Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 05:27:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A77216A4CE for ; Tue, 19 Apr 2005 05:27:23 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2B043D46 for ; Tue, 19 Apr 2005 05:27:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNlGa-0005Q7-1Y for current@freebsd.org; Tue, 19 Apr 2005 07:27:21 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3J5RDxf005123; Tue, 19 Apr 2005 07:27:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Lars Engels From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 19 Apr 2005 01:49:04 +0200." <20050418234904.GB1822@bart.bsd-geek.de> Date: Tue, 19 Apr 2005 07:27:13 +0200 Message-ID: <5122.1113888433@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: Synaptics support and suspend ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 05:27:23 -0000 In message <20050418234904.GB1822@bart.bsd-geek.de>, Lars Engels writes: >On Mon, Apr 18, 2005 at 06:02:25PM +0200, Poul-Henning Kamp wrote: >> >> On my T41p suspend (or rather: resume) does not work if I have >> enabled synaptics support in the psm driver. >> >> There is a t least one problem I can see: the sysctls are >> re-registered, >> but I don't know if that is the main problem. >> > >Do you mean the hw.psm.synaptics_support tunable in the loader.conf? Yes. >On my 5.4-PRERELEASE notebook I had this set for the last months but as >I am still trying to get the extended functions of the pad working in >xorg I deactivated the tunable and did not see any changes in the >behaviour. With 5.3 I needed it to use the tapping function of the pad. > >So, what is the situation like with the synaptics driver? Is thetunable >still needed with 5.4 or -CURRENT? > >Lars > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 05:32:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8822616A4CE for ; Tue, 19 Apr 2005 05:32:33 +0000 (GMT) Received: from mx01.stofanet.dk (mx01.stofanet.dk [212.10.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 066EF43D46 for ; Tue, 19 Apr 2005 05:32:33 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from d40a2021.rev.stofanet.dk ([212.10.32.33] helo=critter.freebsd.dk) by mx01.stofanet.dk (envelope-from ) with esmtp id 1DNlLb-0006k8-2k for freebsd-current@freebsd.org; Tue, 19 Apr 2005 07:32:32 +0200 Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j3J5WSte005266; Tue, 19 Apr 2005 07:32:29 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Conrad J. Sabatier" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 18 Apr 2005 23:24:55 CDT." <20050418232455.2d530890@dolphin.local.net> Date: Tue, 19 Apr 2005 07:32:28 +0200 Message-ID: <5265.1113888748@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 05:32:33 -0000 In message <20050418232455.2d530890@dolphin.local.net>, "Conrad J. Sabatier" wr ites: >> ===> sound/midi (all) >> cc -O -pipe -march=athlon64 -Wno-error -D_KERNEL -DKLD_MODULE >> -nostdinc -I- -include /usr/obj/usr/src/sys/CUSTOM/opt_global.h -I. >> -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g >> -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/CUSTOM -mcmodel=kernel >> -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow >> -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall >> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >> -fformat-extensions -std=c99 -c >> /usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c >> /usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c:204: >> error: unknown field `d_maj' specified in initializer > >When was this member removed, and why? And how to work around this? It is no longer used, just remove it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 09:53:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 755DE16A4CE; Tue, 19 Apr 2005 09:53:28 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE34C43D48; Tue, 19 Apr 2005 09:53:26 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) (8.13.4/8.13.3) with ESMTP id j3J9rOIZ004989 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 19 Apr 2005 11:53:24 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j3J9rNWX004988; Tue, 19 Apr 2005 11:53:23 +0200 (CEST) Date: Tue, 19 Apr 2005 11:53:23 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20050419095323.GA4883@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 cc: sos@freebsd.org Subject: nforce3 sata not probing disks on recent 6-c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 09:53:28 -0000 hi, in recent current my sata disks are not probed any more... verbose dmesg from working kernel attached roman Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #8: Wed Apr 6 10:31:12 UTC 2005 root@sprava:/usr/obj/usr/src/sys/MYKERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80538000. Calibrating clock(s) ... i8254 clock: 1193231 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1808810761 Hz CPU: AMD Athlon(tm) 64 Processor 3000+ (1808.81-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800,LM,3DNow+,3DNow> L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 268369920 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000635000 - 0x000000000f837fff, 253767680 bytes (61955 pages) avail memory = 252043264 (240 MB) mem: null: random: io: cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80004804 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=00e110de) pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f0000000, size 27, enabled found-> vendor=0x10de, dev=0x00e1, revid=0xa1 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x00e0, revid=0xa2 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000e800, size 5, enabled map[20]: type 4, range 32, base 00004c00, size 6, enabled map[24]: type 4, range 32, base 00004c40, size 6, enabled found-> vendor=0x10de, dev=0x00e4, revid=0xa1 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fc003000, size 12, enabled found-> vendor=0x10de, dev=0x00e7, revid=0xa1 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc004000, size 12, enabled found-> vendor=0x10de, dev=0x00e7, revid=0xa1 bus=0, slot=2, func=1 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc005000, size 8, enabled found-> vendor=0x10de, dev=0x00e8, revid=0xa2 bus=0, slot=2, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=c, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc000000, size 12, enabled map[14]: type 4, range 32, base 0000a400, size 3, enabled found-> vendor=0x10de, dev=0x00df, revid=0xa2 bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000a800, size 8, enabled map[14]: type 4, range 32, base 0000ac00, size 7, enabled map[18]: type 1, range 32, base fc001000, size 12, enabled found-> vendor=0x10de, dev=0x00ea, revid=0xa1 bus=0, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x10de, dev=0x00e5, revid=0xa2 bus=0, slot=8, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009e0, size 3, enabled map[14]: type 4, range 32, base 00000be0, size 2, enabled map[18]: type 4, range 32, base 00000960, size 3, enabled map[1c]: type 4, range 32, base 00000b60, size 2, enabled map[20]: type 4, range 32, base 0000c800, size 4, enabled found-> vendor=0x10de, dev=0x00ee, revid=0xa2 bus=0, slot=9, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000009f0, size 3, enabled map[14]: type 4, range 32, base 00000bf0, size 2, enabled map[18]: type 4, range 32, base 00000970, size 3, enabled map[1c]: type 4, range 32, base 00000b70, size 2, enabled map[20]: type 4, range 32, base 0000e000, size 4, enabled found-> vendor=0x10de, dev=0x00e3, revid=0xa2 bus=0, slot=10, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 found-> vendor=0x10de, dev=0x00e2, revid=0xa2 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x00ed, revid=0xa2 bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x02 (500 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0:1:1: Transition from D0 to D3 pci0: at device 2.0 (no driver attached) pci0:2:0: Transition from D0 to D3 pci0: at device 2.1 (no driver attached) pci0:2:1: Transition from D0 to D3 pci0: at device 2.2 (no driver attached) pci0:2:2: Transition from D0 to D3 pci0: at device 5.0 (no driver attached) pci0:5:0: Transition from D0 to D3 pci0: at device 6.0 (no driver attached) pci0:6:0: Transition from D0 to D3 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 8.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=50 ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=ff stat1=10 devices=0x8 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=60 ostat1=70 ata1: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata1: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ata1: [MPSAFE] atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc800-0xc80f irq 11 at device 9.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc800 atapci1: [MPSAFE] ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0xd0 err=0x00 lsb=0x86 msb=0x78 ata2: stat0=0xd0 err=0x00 lsb=0x86 msb=0x78 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] atapci2: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f irq 10 at device 10.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe000 atapci2: [MPSAFE] ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata4: reset tp1 mask=03 ostat0=7f ostat1=7f ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat0=0x7f err=0xff lsb=0xff msb=0xff ata4: stat1=0x7f err=0xff lsb=0xff msb=0xff ata4: reset tp2 stat0=ff stat1=ff devices=0x0 ata4: [MPSAFE] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata5: reset tp1 mask=03 ostat0=7f ostat1=7f ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat0=0x7f err=0xff lsb=0xff msb=0xff ata5: stat1=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=ff devices=0x0 ata5: [MPSAFE] pcib1: at device 11.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x8000-0x8fff pcib1: memory decode 0xf8000000-0xf9ffffff pcib1: prefetched decode 0xe0000000-0xefffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e0000000, size 28, enabled pcib1: (null) requested memory range 0xe0000000-0xefffffff: good map[14]: type 4, range 32, base 00008000, size 8, enabled pcib1: (null) requested I/O range 0x8000-0x80ff: in range map[18]: type 1, range 32, base f9000000, size 16, enabled pcib1: (null) requested memory range 0xf9000000-0xf900ffff: good found-> vendor=0x1002, dev=0x5157, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pcib2: at device 14.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: memory decode 0xfa000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base fb001000, size 11, enabled pcib2: (null) requested memory range 0xfb001000-0xfb0017ff: good map[14]: type 4, range 32, base 00009000, size 7, enabled pcib2: (null) requested I/O range 0x9000-0x907f: in range found-> vendor=0x1106, dev=0x3044, revid=0x46 bus=2, slot=12, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 4, range 32, base 00009400, size 8, enabled pcib2: (null) requested I/O range 0x9400-0x94ff: in range map[14]: type 1, range 32, base fb000000, size 8, enabled pcib2: (null) requested memory range 0xfb000000-0xfb0000ff: good found-> vendor=0x10ec, dev=0x8169, revid=0x10 bus=2, slot=13, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 pci2: at device 12.0 (no driver attached) pci2:12:0: Transition from D0 to D3 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x9400 pcib2: re0 requested I/O range 0x9400-0x94ff: in range pcib2: re0 requested I/O range 0x9400-0x94ff: in range pcib2: re0 requested I/O range 0x9400-0x94ff: in range re0: port 0x9400-0x94ff mem 0xfb000000-0xfb0000ff irq 5 at device 13.0 on pci2 pcib2: re0 requested I/O range 0x9400-0x94ff: in range miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:11:09:d9:b6:61 re0: [MPSAFE] pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xcffff,0xd0000-0xd17ff,0xd2000-0xd2fff on isa0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 1808810761 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on nVidia nForce3 Pro chip acd0: setting UDMA33 on nVidia nForce3 Pro chip acd0: CDROM drive at ata0 as slave acd0: 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 76319MB at ata2-master SATA150 ad4: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 Trying to mount root from ufs:/dev/ad4s2a start_init: trying /sbin/init From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 11:40:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B943416A4CE for ; Tue, 19 Apr 2005 11:40:56 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F2EF43D54 for ; Tue, 19 Apr 2005 11:40:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3JBetsp066255 for ; Tue, 19 Apr 2005 06:40:55 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4264EE1B.9050804@centtech.com> Date: Tue, 19 Apr 2005 06:40:11 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/840/Mon Apr 18 20:42:09 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: Panic during ssh/rsync (rsnapshot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 11:40:56 -0000 I'm using FreeBSD 5.4RC3 (this happened on 5.3R also) as an rsnapshot server. All this machine does, is run rsnapshot (rsync+ssh+hardlinks = snapshot disk backups). I'm running 6 rsnapshot processes via cron every night at 11pm, so it essentially hammers the machine during that time. About 3 out of 5 nights, my system dies right at the beginning with either the fatal trap (see below) or the panic (see below). It seems to die just when I get about 6 rsync processes running. Any ideas? ---------------- panic: sbflush_locked: cc 0 || mb 0xc3432000 || mbcnt 256 cpuid = 0 boot() called on cpu#0 ---------------- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x15 fault code = supervisor read, page not present instruction pointer = 0x8:0xc077ad60 stack pointer = 0x10:0xe898ab10 frame pointer = 0x10:0xe898ab1c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3100 (ssh) trap number = 12 panic: page fault cpuid = 0 -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Apr 18 23:50:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7188316A4CE for ; Mon, 18 Apr 2005 23:50:29 +0000 (GMT) Received: from e.0x20.net (gw.0x20.net [217.69.68.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6793D43D3F for ; Mon, 18 Apr 2005 23:50:28 +0000 (GMT) (envelope-from lars@0x20.net) Received: from bart.bsd-geek.de (dsl-082-083-246-095.arcor-ip.net [82.83.246.95]) (authenticated bits=128) by e.0x20.net (8.13.3/8.13.1/Submit) with ESMTP id j3INoP71093990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Apr 2005 01:50:26 +0200 (CEST) (envelope-from lars@bsd-geek.de) Received: from bart.bsd-geek.de (localhost.bsd-geek.de [127.0.0.1]) by bart.bsd-geek.de (8.13.3/8.13.1) with ESMTP id j3INn5KS002006; Tue, 19 Apr 2005 01:49:05 +0200 (CEST) (envelope-from lars@bart.bsd-geek.de) Received: (from lars@localhost) by bart.bsd-geek.de (8.13.3/8.13.1/Submit) id j3INn4vM002005; Tue, 19 Apr 2005 01:49:04 +0200 (CEST) (envelope-from lars) Date: Tue, 19 Apr 2005 01:49:04 +0200 From: Lars Engels To: Poul-Henning Kamp Message-ID: <20050418234904.GB1822@bart.bsd-geek.de> References: <809.1113840145@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <809.1113840145@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 19 Apr 2005 11:55:09 +0000 cc: current@freebsd.org Subject: Re: Synaptics support and suspend ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 23:50:29 -0000 On Mon, Apr 18, 2005 at 06:02:25PM +0200, Poul-Henning Kamp wrote: > > On my T41p suspend (or rather: resume) does not work if I have > enabled synaptics support in the psm driver. > > There is a t least one problem I can see: the sysctls are > re-registered, > but I don't know if that is the main problem. > Do you mean the hw.psm.synaptics_support tunable in the loader.conf? On my 5.4-PRERELEASE notebook I had this set for the last months but as I am still trying to get the extended functions of the pad working in xorg I deactivated the tunable and did not see any changes in the behaviour. With 5.3 I needed it to use the tapping function of the pad. So, what is the situation like with the synaptics driver? Is thetunable still needed with 5.4 or -CURRENT? Lars From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 12:03:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AAB16A4CE; Tue, 19 Apr 2005 12:03:10 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9FFB43D46; Tue, 19 Apr 2005 12:03:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3JC38Rf066409; Tue, 19 Apr 2005 07:03:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4264F350.2080606@centtech.com> Date: Tue, 19 Apr 2005 07:02:24 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <4262B185.7080100@centtech.com> <426329E6.4090105@root.org> <42641316.9000405@centtech.com> In-Reply-To: <42641316.9000405@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/840/Mon Apr 18 20:42:09 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 12:03:10 -0000 Eric Anderson wrote: > Nate Lawson wrote: > >> Eric Anderson wrote: >> >>> Mark Santcroos wrote: >>> >>>> On Thu, Apr 14, 2005 at 03:50:05PM +0200, Christian Brueffer wrote: >>>> >>>>> looks like acopcode.h and acnames.h are not included in the patch. >>>> >>>> >>>> >>>> >>>> >>>> Oops, rusty cvs skills :) >>>> >>>> The following files have been added to the diff: >>>> abcompare.c abmain.c acnames.h acopcode.h acpibin.h aecommon.h aeexec.c >>>> aemain.c osunixdir.c >>>> >>>> Same location, more fun: >>>> http://www.santcroos.net/mark/freebsd/files/acpi_import_20050408.diff.gz >>>> >>> >>> >>> >>> >>> I just applied this patch, and everything seems to run ok. >>> >>> Only thing I noticed was that I get pauses now about every 6 >>> seconds. All my recent dmesg/sysctl/etc output is here: >>> >>> http://googlebit.com/freebsd/ >>> >>> Eric >> >> >> >> Is there any difference in the embedded controller? You have to boot >> without -v to see its messages (they scrolled in your output). Any >> new warning messages when you get the pause? >> > > It is apparently something in xfce4's battery monitoring plugin. It > hasn't been upgraded or changed since the ACPI changes. Is there > something I can do to see what causes it to choke my machine? I've tested with the new ACPICA, and without, and with it definitely has the pause every 6 seconds (when the battery monitor in xfce4 polls the power stuff?), and without the new ACPICA, it does not exhibit this behaviour. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 12:57:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D620616A4CE; Tue, 19 Apr 2005 12:57:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E05743D41; Tue, 19 Apr 2005 12:57:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JCvDCN008185; Tue, 19 Apr 2005 08:57:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JCvVmh047572; Tue, 19 Apr 2005 08:57:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 384067306E; Tue, 19 Apr 2005 08:57:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419125713.384067306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 08:57:13 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 12:57:15 -0000 TB --- 2005-04-19 11:45:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 11:45:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-04-19 11:45:01 - checking out the source tree TB --- 2005-04-19 11:45:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-04-19 11:45:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 11:51:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 11:51:49 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-04-19 11:51:49 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/pkg_install/version (all) cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/main.c cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/perform.c cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -o pkg_version main.o perform.o /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pkg_install/version/pkg_version.1 > pkg_version.1.gz ===> usr.sbin/pmccontrol (all) cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pmccontrol/../../sys -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pmccontrol/../../lib/libpmc -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pmccontrol/pmccontrol.c make: don't know how to make /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/tmp/usr/lib/libpmc.a. Stop *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-04-19 12:57:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 12:57:12 - ERROR: failed to build world TB --- 2005-04-19 12:57:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 13:20:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23DE016A505 for ; Tue, 19 Apr 2005 13:20:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 877A143D1D for ; Tue, 19 Apr 2005 13:20:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id B905D1FF9A8 for ; Tue, 19 Apr 2005 15:20:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 987051FF90C; Tue, 19 Apr 2005 15:20:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 29095157ED; Tue, 19 Apr 2005 13:15:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 26D8015783 for ; Tue, 19 Apr 2005 13:15:17 +0000 (UTC) Date: Tue, 19 Apr 2005 13:15:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: g_vfs_done fails with strange offsets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 13:20:42 -0000 Hi, I had the same error yesterday when running installworld and it failed at exactly the same point (both cases). da0s1f is the fs holding src and obj only and it had been newfsed -O2 -U in between and I did a new cvs co and buildworld/kernel (still same places I can see this error): install: /usr/share/snmp/mibs/FOKUS-MIB.txt: Bad address this is what gets logged to console. g_vfs_done():da0s1f[READ(offset=-1078889850880, length=2560)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 55985 (install) This is with the kernel from SNAP0002: 6.0-CURRENT-SNAP002 FreeBSD 6.0-CURRENT-SNAP002 #0: Tue Mar 15 19:02:56 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 When booting a kernel compiled from HEAD of the day I can get repeatedly get this with still same installworld as above: ===> include (install) install -C -o root -g wheel -m 444 ..... *** Signal 11 and get this on console: g_vfs_done():da0s1f[READ(offset=-1077929627648, length=2560)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 646 (install) g_vfs_done():da0s1f[READ(offset=-1077929627648, length=2560)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 646 (install) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 13:32:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD07016A4CE; Tue, 19 Apr 2005 13:32:29 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DC2F43D3F; Tue, 19 Apr 2005 13:32:29 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id BE6A81F103; Tue, 19 Apr 2005 15:32:27 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id A07BD615A; Tue, 19 Apr 2005 15:32:27 +0200 (CEST) Date: Tue, 19 Apr 2005 15:32:27 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050419133227.GA11612@stack.nl> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20050418203321.GA88774@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 13:32:30 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2005 at 10:33:21PM +0200, Marc Olzheim wrote: > On Mon, Apr 18, 2005 at 04:22:13PM -0400, Brian Fundakowski Feldman wrote: > > > > http://green.homeunix.org/~green/nfs_client.deadlock.patch > > > Hmm, could you change it into a diff -u ? > >=20 > > I replaced the patch with one with -u for you. >=20 > Ok, great, I'll do some test on my -CURRENT machine at work > in the morning (CEST). Hmm, sys/vnode.h has changed a lot from RELENG_5 to -CURRENT... Perhaps someone with insight in this overhaul could change the patch to HEAD ? Marc --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZQhrezjnobFOgrERAoMsAJ9S4VosY4rqKCWV0h4v1nShS0FC2wCguh88 sotR5t18dvrEEIVedODVwh0= =54nw -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 14:47:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83B3716A4CE; Tue, 19 Apr 2005 14:47:51 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 657B043D5E; Tue, 19 Apr 2005 14:47:48 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JElh4p018156; Tue, 19 Apr 2005 10:47:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JElhni045999; Tue, 19 Apr 2005 10:47:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 282A27306E; Tue, 19 Apr 2005 10:47:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419144743.282A27306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 10:47:43 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 14:47:51 -0000 TB --- 2005-04-19 12:57:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 12:57:13 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-19 12:57:13 - checking out the source tree TB --- 2005-04-19 12:57:13 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-19 12:57:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 13:03:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 13:03:59 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-19 13:03:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-04-19 14:23:13 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 14:23:13 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-19 14:23:13 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 19 14:23:13 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Apr 19 14:38:56 UTC 2005 TB --- 2005-04-19 14:38:56 - generating LINT kernel config TB --- 2005-04-19 14:38:56 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-19 14:38:56 - /usr/bin/make -B LINT TB --- 2005-04-19 14:38:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 14:38:56 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-19 14:38:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 19 14:38:57 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/gnu/ext2fs/ext2_linux_ialloc.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/gnu/ext2fs/ext2_lookup.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/gnu/ext2fs/ext2_subr.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/gnu/ext2fs/ext2_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/gnu/ext2fs/ext2_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/hwpmc/hwpmc_mod.c /tinderbox/CURRENT/amd64/amd64/src/sys/hwpmc/hwpmc_mod.c: In function `pmc_debugflags_parse': /tinderbox/CURRENT/amd64/amd64/src/sys/hwpmc/hwpmc_mod.c:306: warning: 'e' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-19 14:47:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 14:47:42 - ERROR: failed to build lint kernel TB --- 2005-04-19 14:47:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 15:19:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 58C4B16A4CE; Tue, 19 Apr 2005 15:19:01 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3JFI09A041298; Tue, 19 Apr 2005 11:18:00 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3JFI0cI041297; Tue, 19 Apr 2005 11:18:00 -0400 (EDT) (envelope-from green) Date: Tue, 19 Apr 2005 11:18:00 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050419151800.GE1157@green.homeunix.org> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419133227.GA11612@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 15:19:01 -0000 On Tue, Apr 19, 2005 at 03:32:27PM +0200, Marc Olzheim wrote: > On Mon, Apr 18, 2005 at 10:33:21PM +0200, Marc Olzheim wrote: > > On Mon, Apr 18, 2005 at 04:22:13PM -0400, Brian Fundakowski Feldman wrote: > > > > > http://green.homeunix.org/~green/nfs_client.deadlock.patch > > > > Hmm, could you change it into a diff -u ? > > > > > > I replaced the patch with one with -u for you. > > > > Ok, great, I'll do some test on my -CURRENT machine at work > > in the morning (CEST). > > Hmm, sys/vnode.h has changed a lot from RELENG_5 to -CURRENT... Perhaps > someone with insight in this overhaul could change the patch to HEAD ? Does this work for you? cvs diff: Diffing sys Index: sys/buf.h =================================================================== RCS file: /usr/ncvs/src/sys/sys/buf.h,v retrieving revision 1.185 diff -u -r1.185 buf.h --- sys/buf.h 10 Feb 2005 12:17:48 -0000 1.185 +++ sys/buf.h 19 Apr 2005 14:30:54 -0000 @@ -465,6 +465,7 @@ extern int maxswzone; /* Max KVA for swap structures */ extern int maxbcache; /* Max KVA for buffer cache */ extern int runningbufspace; +extern int hibufspace; extern int buf_maxio; /* nominal maximum I/O for buffer */ extern struct buf *buf; /* The buffer headers. */ extern char *buffers; /* The buffer contents. */ cvs diff: Diffing kern Index: kern/vfs_bio.c =================================================================== RCS file: /usr/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.482 diff -u -r1.482 vfs_bio.c --- kern/vfs_bio.c 25 Mar 2005 00:20:37 -0000 1.482 +++ kern/vfs_bio.c 19 Apr 2005 14:30:54 -0000 @@ -127,7 +127,7 @@ static int lobufspace; SYSCTL_INT(_vfs, OID_AUTO, lobufspace, CTLFLAG_RD, &lobufspace, 0, "Minimum amount of buffers we want to have"); -static int hibufspace; +int hibufspace; SYSCTL_INT(_vfs, OID_AUTO, hibufspace, CTLFLAG_RD, &hibufspace, 0, "Maximum allowed value of bufspace (excluding buf_daemon)"); static int bufreusecnt; cvs diff: Diffing nfsclient Index: nfsclient/nfs_bio.c =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfs_bio.c,v retrieving revision 1.150 diff -u -r1.150 nfs_bio.c --- nfsclient/nfs_bio.c 18 Mar 2005 21:23:32 -0000 1.150 +++ nfsclient/nfs_bio.c 19 Apr 2005 15:11:13 -0000 @@ -844,6 +844,7 @@ struct vattr vattr; struct nfsmount *nmp = VFSTONFS(vp->v_mount); daddr_t lbn; + off_t commitleft; /* if non-zero, the amount left we may write */ int bcount; int n, on, error = 0; int haverslock = 0; @@ -873,6 +874,14 @@ */ if (ioflag & (IO_APPEND | IO_SYNC)) { if (np->n_flag & NMODIFIED) { +flush_and_restart: + /* + * Require non-blocking, synchronous writes to + * dirty files to inform the program it needs + * to fsync(2) explicitly. + */ + if (ioflag & IO_NDELAY) + return (EAGAIN); np->n_attrstamp = 0; error = nfs_vinvalbuf(vp, V_SAVE, td, 1); if (error) @@ -953,12 +962,65 @@ } biosize = vp->v_mount->mnt_stat.f_iosize; + commitleft = 0; + /* + * If there are possible modifications, find all of this file's + * B_NEEDCOMMIT buffers. If our writes would exceed the local + * maximum per-file write commit size when combined with those, + * we decide to flush and/or do a short write. + */ + if ((ioflag & (IO_SYNC | IO_INVAL)) != (IO_SYNC | IO_INVAL)) { + commitleft = nmp->nm_wcommitsize; + if (np->n_flag & NMODIFIED) { + int wouldcommit = 0; + BO_LOCK(vp->v_bufobj); + if (vp->v_bufobj.bo_dirty.bv_cnt != 0) { + TAILQ_FOREACH(bp, &vp->v_bufobj.bo_dirty.bv_hd, + b_bobufs) { + if (bp->b_flags & B_NEEDCOMMIT) + wouldcommit += bp->b_bcount; + } + } + BO_UNLOCK(vp->v_bufobj); + /* + * Since we're not operating synchronously and + * bypassing the buffer cache, we are in a commit + * and holding all of these buffers whether + * transmitted or not. If not limited, this + * will lead to the buffer cache deadlocking, + * as no one else can flush our uncommitted buffers. + */ + wouldcommit += uio->uio_resid; + /* + * If we would initially exceed the maximum + * outstanding write commit size, flush and restart. + */ + if (wouldcommit > commitleft) { + if (haverslock) { + nfs_rsunlock(np, td); + haverslock = 0; + } + goto flush_and_restart; + } + } else { + /* + * With no outstanding commits, we are limited only + * by commitleft as to how far we can go. + */ + } + } do { nfsstats.biocache_writes++; lbn = uio->uio_offset / biosize; on = uio->uio_offset & (biosize-1); n = min((unsigned)(biosize - on), uio->uio_resid); + /* Always allow at least the very first write. */ + if (commitleft > 0) { + commitleft -= n; + if (commitleft == 0) + commitleft = -1; + } again: /* * Handle direct append and file extension cases, calculate @@ -1146,10 +1208,21 @@ } else { bdwrite(bp); } - } while (uio->uio_resid > 0 && n > 0); + } while (uio->uio_resid > 0 && n > 0 && commitleft >= 0); - if (haverslock) + if (haverslock) { + haverslock = 0; nfs_rsunlock(np, td); + } + + /* + * On the off chance that we're trying to do a very large + * and non-atomic write, go ahead and let that just continue + * within the same call after flushing out what's been written. + */ + if (error == 0 && uio->uio_resid > 0 && n > 0 && commitleft < 0 && + !(ioflag & IO_UNIT)) + goto flush_and_restart; return (error); } Index: nfsclient/nfs_vfsops.c =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfs_vfsops.c,v retrieving revision 1.172 diff -u -r1.172 nfs_vfsops.c --- nfsclient/nfs_vfsops.c 24 Mar 2005 07:37:22 -0000 1.172 +++ nfsclient/nfs_vfsops.c 19 Apr 2005 14:32:19 -0000 @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include #include @@ -626,6 +628,12 @@ else nmp->nm_readahead = NFS_MAXRAHEAD; } + if ((argp->flags & NFSMNT_WCOMMITSIZE) && argp->wcommitsize >= 0) { + if (argp->wcommitsize < nmp->nm_wsize) + nmp->nm_wcommitsize = nmp->nm_wsize; + else + nmp->nm_wcommitsize = argp->wcommitsize; + } if ((argp->flags & NFSMNT_DEADTHRESH) && argp->deadthresh >= 0) { if (argp->deadthresh <= NFS_MAXDEADTHRESH) nmp->nm_deadthresh = argp->deadthresh; @@ -808,6 +816,7 @@ nmp->nm_wsize = NFS_WSIZE; nmp->nm_rsize = NFS_RSIZE; } + nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); nmp->nm_readdirsize = NFS_READDIRSIZE; nmp->nm_numgrps = NFS_MAXGRPS; nmp->nm_readahead = NFS_DEFRAHEAD; Index: nfsclient/nfsargs.h =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfsargs.h,v retrieving revision 1.67 diff -u -r1.67 nfsargs.h --- nfsclient/nfsargs.h 7 Jan 2005 01:45:51 -0000 1.67 +++ nfsclient/nfsargs.h 19 Apr 2005 14:30:54 -0000 @@ -56,7 +56,7 @@ int retrans; /* times to retry send */ int maxgrouplist; /* Max. size of group list */ int readahead; /* # of blocks to readahead */ - int __pad1; /* was "leaseterm" */ + int wcommitsize; /* Max. write commit size in bytes */ int deadthresh; /* Retrans threshold */ char *hostname; /* server's name */ int acregmin; /* cache attrs for reg files min time */ @@ -80,7 +80,7 @@ #define NFSMNT_NFSV3 0x00000200 /* Use NFS Version 3 protocol */ /* 0x400 free, was NFSMNT_KERB */ #define NFSMNT_DUMBTIMR 0x00000800 /* Don't estimate rtt dynamically */ -/* 0x1000 free, was NFSMNT_LEASETERM */ +#define NFSMNT_WCOMMITSIZE 0x00001000 /* set max write commit size */ #define NFSMNT_READAHEAD 0x00002000 /* set read ahead */ #define NFSMNT_DEADTHRESH 0x00004000 /* set dead server retry thresh */ #define NFSMNT_RESVPORT 0x00008000 /* Allocate a reserved port */ Index: nfsclient/nfsmount.h =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfsmount.h,v retrieving revision 1.29 diff -u -r1.29 nfsmount.h --- nfsclient/nfsmount.h 7 Jan 2005 01:45:51 -0000 1.29 +++ nfsclient/nfsmount.h 19 Apr 2005 14:30:54 -0000 @@ -74,6 +74,7 @@ int nm_wsize; /* Max size of write rpc */ int nm_readdirsize; /* Size of a readdir rpc */ int nm_readahead; /* Num. of blocks to readahead */ + int nm_wcommitsize; /* Max size of commit for write */ int nm_acdirmin; /* Directory attr cache min lifetime */ int nm_acdirmax; /* Directory attr cache max lifetime */ int nm_acregmin; /* Reg file attr cache min lifetime */ -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 15:30:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B9BC16A4CE for ; Tue, 19 Apr 2005 15:30:58 +0000 (GMT) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C6743D55 for ; Tue, 19 Apr 2005 15:30:57 +0000 (GMT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost.energistic.com [127.0.0.1]) by energistic.com (8.13.3/8.13.3) with ESMTP id j3JFUv8W033465 for ; Tue, 19 Apr 2005 10:30:57 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.13.3/8.13.3/Submit) id j3JFUvWD030545 for freebsd-current@freebsd.org; Tue, 19 Apr 2005 10:30:57 -0500 (EST) (envelope-from steve) Date: Tue, 19 Apr 2005 10:30:57 -0500 (EST) From: Steve Ames Message-Id: <200504191530.j3JFUvWD030545@energistic.com> To: freebsd-current@freebsd.org X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on energistic.com Subject: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 15:30:58 -0000 I just noticed yesterday that there hasn't been an update to /boot/kernel.old since sometime in August. Yesterday was my first bad kernel on -CURRENT and I fell back to /boot/kernel.old/kernel and was suprised that it was that old. When did 'make kernel' stop copying /boot/kernel to /boot/kernel.old? It still seems to have that behavior on 5.X. I checked UPDATING but didn't see anything on this behavior change. Nor could I find a knob in make.conf. Is this user error somewhere? -Steve From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 15:36:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3C9B16A4CE for ; Tue, 19 Apr 2005 15:36:01 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4961A43D58 for ; Tue, 19 Apr 2005 15:36:01 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3JFZxu3035588; Tue, 19 Apr 2005 10:35:59 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42652533.8060106@centtech.com> Date: Tue, 19 Apr 2005 10:35:15 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Ames References: <200504191530.j3JFUvWD030545@energistic.com> In-Reply-To: <200504191530.j3JFUvWD030545@energistic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 15:36:02 -0000 Steve Ames wrote: > I just noticed yesterday that there hasn't been an update to /boot/kernel.old > since sometime in August. Yesterday was my first bad kernel on -CURRENT and > I fell back to /boot/kernel.old/kernel and was suprised that it was that old. > > When did 'make kernel' stop copying /boot/kernel to /boot/kernel.old? It still > seems to have that behavior on 5.X. I checked UPDATING but didn't see anything > on this behavior change. Nor could I find a knob in make.conf. > > Is this user error somewhere? Using 'make buildkernel ...' and 'make installkernel ...' does the kernel.old dance correctly. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:03:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D19FA16A4CE; Tue, 19 Apr 2005 16:03:00 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F36D243D1D; Tue, 19 Apr 2005 16:02:59 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 0CBDF1F110; Tue, 19 Apr 2005 18:02:59 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id E5326615A; Tue, 19 Apr 2005 18:02:58 +0200 (CEST) Date: Tue, 19 Apr 2005 18:02:58 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050419160258.GA12287@stack.nl> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20050419151800.GE1157@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:03:01 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote: > Does this work for you? ... cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/nfsclient/nfs_bio.c /usr/src/sys/nfsclient/nfs_bio.c: In function `nfs_write': /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' *** Error code 1 Mac --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZSuyezjnobFOgrERAnUgAJ9YW1TUn6TJdlo/aswhffqH74EgbACfZmjS RIkNxmHiW7k2vO9X/i6uIlQ= =PjU1 -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:06:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D9A616A4CE for ; Tue, 19 Apr 2005 16:06:28 +0000 (GMT) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 827A443D49 for ; Tue, 19 Apr 2005 16:06:27 +0000 (GMT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost.energistic.com [127.0.0.1]) by energistic.com (8.13.3/8.13.3) with ESMTP id j3JG6NQh050081; Tue, 19 Apr 2005 11:06:23 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.13.3/8.13.3/Submit) id j3JG6NJc048429; Tue, 19 Apr 2005 11:06:23 -0500 (EST) (envelope-from steve) Date: Tue, 19 Apr 2005 11:06:23 -0500 From: Steve Ames To: Steve Ames Message-ID: <20050419160623.GA2922@energistic.com> References: <200504191530.j3JFUvWD030545@energistic.com> <42652533.8060106@centtech.com> <001501c544f5$f6fc3fd0$9b00030a@officescape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c544f5$f6fc3fd0$9b00030a@officescape.net> User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_63, SPF_HELO_PASS,SPF_PASS,USER_IN_WHITELIST_TO autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on energistic.com cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:06:28 -0000 No. doing 'make buildkernel' and 'make installkernel' seperately does not cause /boot/kernel to be copied to /boot/kernel.old. -Steve On Tue, Apr 19, 2005 at 10:39:23AM -0500, Steve Ames wrote: > I'm trying that now. However on 5.x 'make kernel' installs a kernel.old. On > 6.x: > > basement# make -n kernel > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x > /usr/obj/usr/src/make.i386/make ]; then echo > /usr/obj/usr/src/make.i386/make; else echo make; fi` -m > /usr/src/share/mk -f Makefile.inc1 buildkernel > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x > /usr/obj/usr/src/make.i386/make ]; then echo > /usr/obj/usr/src/make.i386/make; else echo make; fi` -m > /usr/src/share/mk -f Makefile.inc1 installkernel > > 'make kernel' executed both 'make buildkernel' and 'make installkernel' so > I'm guessing it won't but I'll know for sure in a few minutes. > > -Steve > > ----- Original Message ----- > From: "Eric Anderson" > To: "Steve Ames" > Cc: > Sent: Tuesday, April 19, 2005 10:35 AM > Subject: Re: kernel.old not used any longer? > > > > Steve Ames wrote: > > > I just noticed yesterday that there hasn't been an update to > /boot/kernel.old > > > since sometime in August. Yesterday was my first bad kernel on -CURRENT > and > > > I fell back to /boot/kernel.old/kernel and was suprised that it was that > old. > > > > > > When did 'make kernel' stop copying /boot/kernel to /boot/kernel.old? It > still > > > seems to have that behavior on 5.X. I checked UPDATING but didn't see > anything > > > on this behavior change. Nor could I find a knob in make.conf. > > > > > > Is this user error somewhere? > > > > Using 'make buildkernel ...' and 'make installkernel ...' does the > kernel.old > > dance correctly. > > > > Eric > > > > > > > > -- > > ------------------------------------------------------------------------ > > Eric Anderson Sr. Systems Administrator Centaur Technology > > A lost ounce of gold may be found, a lost moment of time never. > > ------------------------------------------------------------------------ > > > From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:09:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16B1916A4CE; Tue, 19 Apr 2005 16:09:02 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B830143D31; Tue, 19 Apr 2005 16:09:01 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 2300F1F110; Tue, 19 Apr 2005 18:09:01 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 05457615A; Tue, 19 Apr 2005 18:09:00 +0200 (CEST) Date: Tue, 19 Apr 2005 18:09:00 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050419160900.GB12287@stack.nl> References: <20050415050821.GO981@green.homeunix.org> <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20050419160258.GA12287@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:09:02 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote: > On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote: > > Does this work for you? >=20 > ... >=20 > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-ex= tensions -std=3Dc99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/con= trib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter= -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/co= ntrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -= D_KERNEL -include opt_global.h -fno-common -finline-limit=3D8000 --param in= line-unit-growth=3D100 --param large-function-growth=3D1000 -mno-align-lon= g-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno= -sse2 -ffreestanding -Werror /usr/src/sys/nfsclient/nfs_bio.c > /usr/src/sys/nfsclient/nfs_bio.c: In function `nfs_write': > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > *** Error code 1 That's about the BO_LOCK(vp->v_bufobj); and the BO_UNLOCK(vp->v_bufobj); Marc --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZS0cezjnobFOgrERAq8DAKCgY7RxdUXoXxn82VqsHL+8E6ipfQCgu8aa XRz3rvCIHRMZ8fWKrtbBSog= =b9j1 -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:17:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7563D16A4CE; Tue, 19 Apr 2005 16:17:19 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3JGGG2X042458; Tue, 19 Apr 2005 12:16:16 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3JGGGYU042457; Tue, 19 Apr 2005 12:16:16 -0400 (EDT) (envelope-from green) Date: Tue, 19 Apr 2005 12:16:16 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050419161616.GF1157@green.homeunix.org> References: <20050415132108.GC85922@stack.nl> <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419160900.GB12287@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:17:19 -0000 On Tue, Apr 19, 2005 at 06:09:00PM +0200, Marc Olzheim wrote: > On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote: > > On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote: > > > Does this work for you? > > > > ... > > > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/nfsclient/nfs_bio.c > > /usr/src/sys/nfsclient/nfs_bio.c: In function `nfs_write': > > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > > *** Error code 1 > > That's about the BO_LOCK(vp->v_bufobj); and the BO_UNLOCK(vp->v_bufobj); Yeah, I get that too. I have no clue why it's doing that, I was figuring it was just my compile setup... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:29:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A6BC16A4CE for ; Tue, 19 Apr 2005 16:29:04 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8F543D39 for ; Tue, 19 Apr 2005 16:29:04 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 86B9D1F102; Tue, 19 Apr 2005 18:29:03 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 69757615A; Tue, 19 Apr 2005 18:29:03 +0200 (CEST) Date: Tue, 19 Apr 2005 18:29:03 +0200 From: Marc Olzheim To: Steve Ames Message-ID: <20050419162903.GA12342@stack.nl> References: <200504191530.j3JFUvWD030545@energistic.com> <42652533.8060106@centtech.com> <001501c544f5$f6fc3fd0$9b00030a@officescape.net> <20050419160623.GA2922@energistic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20050419160623.GA2922@energistic.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Steve Ames cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:29:04 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 19, 2005 at 11:06:23AM -0500, Steve Ames wrote: > No. doing 'make buildkernel' and 'make installkernel' seperately does > not cause /boot/kernel to be copied to /boot/kernel.old. /usr/src/Makefile: kernel: buildkernel installkernel No difference in doing it separately. cd /usr/obj/usr/src/sys/ ; make -n install gives me: ... thiskernel=`sysctl -n kern.bootfile` ; if [ "`dirname "$thiskernel"`" != /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi ... What so you get ? Marc --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZTHPezjnobFOgrERAimsAKDKdNSX7FADkR7w6XLSAO6gAPUTMACgnj9j FeeJe6ohCgZILSujKuWz+Aw= =7Wp4 -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:30:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D763B16A567; Tue, 19 Apr 2005 16:30:33 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E231643D2F; Tue, 19 Apr 2005 16:30:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JGUWZF027578; Tue, 19 Apr 2005 12:30:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JGUW6n009484; Tue, 19 Apr 2005 12:30:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0E7317306E; Tue, 19 Apr 2005 12:30:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419163031.0E7317306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 12:30:31 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:30:34 -0000 TB --- 2005-04-19 14:47:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 14:47:43 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-19 14:47:43 - checking out the source tree TB --- 2005-04-19 14:47:43 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-19 14:47:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 14:54:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 14:54:29 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-19 14:54:29 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-19 16:03:39 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 16:03:39 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-19 16:03:39 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 19 16:03:39 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Apr 19 16:21:46 UTC 2005 TB --- 2005-04-19 16:21:46 - generating LINT kernel config TB --- 2005-04-19 16:21:46 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-19 16:21:46 - /usr/bin/make -B LINT TB --- 2005-04-19 16:21:47 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 16:21:47 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-19 16:21:47 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 19 16:21:47 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/gnu/ext2fs/ext2_linux_ialloc.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/gnu/ext2fs/ext2_lookup.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/gnu/ext2fs/ext2_subr.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/gnu/ext2fs/ext2_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/gnu/ext2fs/ext2_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/hwpmc/hwpmc_mod.c /tinderbox/CURRENT/i386/i386/src/sys/hwpmc/hwpmc_mod.c: In function `pmc_debugflags_parse': /tinderbox/CURRENT/i386/i386/src/sys/hwpmc/hwpmc_mod.c:306: warning: 'e' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-19 16:30:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 16:30:31 - ERROR: failed to build lint kernel TB --- 2005-04-19 16:30:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 16:52:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F1C916A4CE for ; Tue, 19 Apr 2005 16:52:31 +0000 (GMT) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C85743D46 for ; Tue, 19 Apr 2005 16:52:30 +0000 (GMT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost.energistic.com [127.0.0.1]) by energistic.com (8.13.3/8.13.3) with ESMTP id j3JGqRHN040089; Tue, 19 Apr 2005 11:52:27 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.13.3/8.13.3/Submit) id j3JGqRFD037751; Tue, 19 Apr 2005 11:52:27 -0500 (EST) (envelope-from steve) Date: Tue, 19 Apr 2005 11:52:27 -0500 From: Steve Ames To: Marc Olzheim Message-ID: <20050419165227.GA86651@energistic.com> References: <200504191530.j3JFUvWD030545@energistic.com> <42652533.8060106@centtech.com> <001501c544f5$f6fc3fd0$9b00030a@officescape.net> <20050419160623.GA2922@energistic.com> <20050419162903.GA12342@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419162903.GA12342@stack.nl> User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_63, SPF_HELO_PASS,SPF_PASS,USER_IN_WHITELIST_TO autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on energistic.com cc: Steve Ames cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 16:52:31 -0000 On Tue, Apr 19, 2005 at 06:29:03PM +0200, Marc Olzheim wrote: > cd /usr/obj/usr/src/sys/ ; make -n install gives me: > ... > thiskernel=`sysctl -n kern.bootfile` ; if [ "`dirname "$thiskernel"`" > != /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf > /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R > noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv > /boot/kernel /boot/kernel.old ; sysctl > kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi > ... > > > What so you get ? Hrm. Almost the same as you. On mine that first comparison is actually "!= //boot/kernel". Likely because I have "DESTDIR?=/" in /etc/make.conf. Hrm. Suddenly all makes sense. I defined DESTDIR so that 'make world' would continue to work normally (instead of doing buildworld/installworld) and that probably happened around August '04. So I guess if I get rid of DESTDIR and start doing buildworld/installworld then I get kernel.old functionality again... however this tastes like a bug to me. Perhaps that comparison should be: "!= ${DESTIR}/boot/kernel" ?? -Steve From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 17:01:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D308E16A4CE; Tue, 19 Apr 2005 17:01:14 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6247643D41; Tue, 19 Apr 2005 17:01:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JH1C88026921; Tue, 19 Apr 2005 13:01:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JH1Cw7050584; Tue, 19 Apr 2005 13:01:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A3BF27306E; Tue, 19 Apr 2005 13:01:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419170112.A3BF27306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 13:01:12 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 17:01:15 -0000 TB --- 2005-04-19 16:30:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 16:30:32 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-04-19 16:30:32 - checking out the source tree TB --- 2005-04-19 16:30:32 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-04-19 16:30:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 16:37:19 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 16:37:19 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-04-19 16:37:19 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sed 's/.*/char pcap_version[] = "&";/' /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/VERSION > version.c rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -Dyylval=pcapyylval -I/tinderbox/CURRENT/i386/pc98/src/lib/libpcap -I. -D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -I/tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap grammar.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/pcap.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/inet.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/fad-getad.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/gencode.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/optimize.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/etherent.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/savefile.c /tinderbox/CURRENT/i386/pc98/src /lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /tinderbox/CURRENT/i386/pc98/src/lib/libpcap/../../contrib/libpcap/bpf_dump.c scanner.c version.c ===> lib/libpmc (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/i386/pc98/src/lib/libpmc/libpmc.c /tinderbox/CURRENT/i386/pc98/src/lib/libpmc/libpmc.c:37:30: machine/pmc_mdep.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/lib/libpmc. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-04-19 17:01:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 17:01:12 - ERROR: failed to build world TB --- 2005-04-19 17:01:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 18:00:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6493E16A4CE for ; Tue, 19 Apr 2005 18:00:50 +0000 (GMT) Received: from lakermmtao06.cox.net (lakermmtao06.cox.net [68.230.240.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B30F43D2F for ; Tue, 19 Apr 2005 18:00:49 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP <20050419180049.DHNN21504.lakermmtao06.cox.net@dolphin.local.net>; Tue, 19 Apr 2005 14:00:49 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3JI0mRv001273; Tue, 19 Apr 2005 13:00:48 -0500 (CDT) (envelope-from conrads@cox.net) Date: Tue, 19 Apr 2005 13:00:48 -0500 From: "Conrad J. Sabatier" To: "Poul-Henning Kamp" Message-ID: <20050419130048.6e545269@dolphin.local.net> In-Reply-To: <5265.1113888748@critter.freebsd.dk> References: <20050418232455.2d530890@dolphin.local.net> <5265.1113888748@critter.freebsd.dk> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 18:00:50 -0000 On Tue, 19 Apr 2005 07:32:28 +0200, "Poul-Henning Kamp" wrote: > In message <20050418232455.2d530890@dolphin.local.net>, "Conrad J. > Sabatier" wr ites: > > > >When was this member removed, and why? And how to work around this? > > It is no longer used, just remove it. OK, thanks. I commented out all references to d_maj in Mat's code, and it compiles just fine. Still no support for my particular soundcard yet, though, unfortunately (es137x), but Mat does intend to get to work on it Real Soon Now. It looks like MIDI is really starting to come together, though. I now have a loadable kernel module "midi.ko", with support for cmi and emu10k1 cards. I've already seen a report from someone on the multimedia list who actually got this to work with his card and external MIDI synth. Hopefully, we can get support for more cards included soon. :-) We'll keep the current list informed as to further developments. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 18:31:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C004116A4CE for ; Tue, 19 Apr 2005 18:31:27 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DEF843D2F for ; Tue, 19 Apr 2005 18:31:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6A8A2513EE; Tue, 19 Apr 2005 11:31:26 -0700 (PDT) Date: Tue, 19 Apr 2005 11:31:25 -0700 From: Kris Kennaway To: Eric Anderson Message-ID: <20050419183125.GA60061@xor.obsecurity.org> References: <4264EE1B.9050804@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <4264EE1B.9050804@centtech.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current Subject: Re: Panic during ssh/rsync (rsnapshot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 18:31:27 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 06:40:11AM -0500, Eric Anderson wrote: > I'm using FreeBSD 5.4RC3 (this happened on 5.3R also) as an rsnapshot=20 > server. All this machine does, is run rsnapshot (rsync+ssh+hardlinks =3D= =20 > snapshot disk backups). I'm running 6 rsnapshot processes via cron every= =20 > night at 11pm, so it essentially hammers the machine during that time. = =20 > About 3 out of 5 nights, my system dies right at the beginning with eithe= r=20 > the fatal trap (see below) or the panic (see below). It seems to die jus= t=20 > when I get about 6 rsync processes running. >=20 > Any ideas? Please try to obtain a debugging traceback as described in the chapter on kernel debugging in the Developers' Handbook. Also, problems with FreeBSD-STABLE should be sent to freebsd-stable@FreeBSD.org. Thanks, Kris --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZU59Wry0BWjoQKURAnZTAKCjHe92qYyEaRfYDbqI28AGm6LbkACggI0U JfmnjUmbQZrTlqIyIjE4J8c= =Cruc -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 18:41:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E41B16A4CE; Tue, 19 Apr 2005 18:41:16 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97DB843D1F; Tue, 19 Apr 2005 18:41:15 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JIfFQw037652; Tue, 19 Apr 2005 14:41:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JIfF2J099789; Tue, 19 Apr 2005 14:41:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0BFA37306E; Tue, 19 Apr 2005 14:41:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419184115.0BFA37306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 14:41:15 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 18:41:16 -0000 TB --- 2005-04-19 17:01:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 17:01:12 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-04-19 17:01:12 - checking out the source tree TB --- 2005-04-19 17:01:12 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-04-19 17:01:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 17:07:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 17:07:29 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-19 17:07:29 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-19 18:39:32 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 18:39:32 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-04-19 18:39:32 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 19 18:39:32 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] machine -> /tinderbox/CURRENT/ia64/ia64/src/sys/ia64/include rm -f .depend GPATH GRTAGS GSYMS GTAGS rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c In file included from /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c:40: @/sys/pmc.h:1120:2: #error Unsupported PMC architecture. /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c:53:30: machine/pmc_mdep.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-04-19 18:41:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 18:41:14 - ERROR: failed to build generic kernel TB --- 2005-04-19 18:41:14 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 19:16:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9155716A4CE; Tue, 19 Apr 2005 19:16:30 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57A4743D55; Tue, 19 Apr 2005 19:16:30 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j3JJGQeJ016193; Tue, 19 Apr 2005 12:16:27 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050419184115.0BFA37306E@freebsd-current.sentex.ca> References: <20050419184115.0BFA37306E@freebsd-current.sentex.ca> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 19 Apr 2005 12:16:26 -0700 To: FreeBSD Tinderbox X-Mailer: Apple Mail (2.622) cc: current@freebsd.org cc: ia64@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 19:16:30 -0000 On Apr 19, 2005, at 11:41 AM, FreeBSD Tinderbox wrote: > machine -> /tinderbox/CURRENT/ia64/ia64/src/sys/ia64/include > rm -f .depend GPATH GRTAGS GSYMS GTAGS > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ > -I@/contrib/altq -I@/../include -I/usr/include > -I/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/ > src/sys/GENERIC > /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/ > hwpmc_mod.c > In file included from > /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/ > hwpmc_mod.c:40: > @/sys/pmc.h:1120:2: #error Unsupported PMC architecture. > /tinderbox/CURRENT/ia64/ia64/src/sys/modules/hwpmc/../../hwpmc/ > hwpmc_mod.c:53:30: machine/pmc_mdep.h: No such file or directory > mkdep: compile failed > *** Error code 1 FYI: I'm on it, but the tinderbox will continue to fail until I have something to commit. This should be in a couple of days at the most. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 19:18:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1932116A4CE for ; Tue, 19 Apr 2005 19:18:33 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7268143D2D for ; Tue, 19 Apr 2005 19:18:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3JJFYWj031071; Tue, 19 Apr 2005 13:15:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Apr 2005 13:15:34 -0600 (MDT) Message-Id: <20050419.131534.41663830.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <42648C95.3010102@samsco.org> References: <20050418232455.2d530890@dolphin.local.net> <42648C95.3010102@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: conrads@cox.net cc: freebsd-current@freebsd.org cc: mat@cnd.mcgill.ca Subject: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 19:18:33 -0000 From: Scott Long Subject: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT? Date: Mon, 18 Apr 2005 22:44:05 -0600 > Conrad J. Sabatier wrote: > > I've been trying to help Mat Kanner with his yet-to-be-committed MIDI > > patches, and have run into a perplexing problem on amd64 CURRENT. It > > seems the "d_maj" member of "struct cdevsw" no longer exists (in > > sys/sys/conf.h). This is causing Mat's MIDI patches to fail with: > > > > > > > >>===> sound/midi (all) > >>cc -O -pipe -march=athlon64 -Wno-error -D_KERNEL -DKLD_MODULE > >>-nostdinc -I- -include /usr/obj/usr/src/sys/CUSTOM/opt_global.h -I. > >>-I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g > >>-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/CUSTOM -mcmodel=kernel > >>-mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow > >>-msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall > >>-Wredundant-decls -Wnested-externs -Wstrict-prototypes > >>-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > >>-fformat-extensions -std=c99 -c > >>/usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c > >>/usr/src/sys/modules/sound/midi/../../../dev/sound/midi/midi.c:204: > >>error: unknown field `d_maj' specified in initializer > > > > > > When was this member removed, and why? And how to work around this? > > > > Thanks! > > > > Major numbers are now dynamically assigned. The shims for allowing > drivers to choose a static major number were removed a few months ago. > There is no work-around for this; just don't include the field anymore > in 6-current sources. If there is something that thinks it needs > explicit knowledge of major numbers, let me know and we can discuss how > to fix it. I have a few drivers I have to maintain on both 5.x and 6.x, and I've been doing #ifdef MAJOR_AUTO .d_maj = MyMajorHere #endif if I care about the major, usually because the driver also has to work on 4.x too. However, if you don't have such constraints, just removing it is best. Warner From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 20:48:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 87DF716A4CE; Tue, 19 Apr 2005 20:48:35 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3JKlNEK051038; Tue, 19 Apr 2005 16:47:24 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3JKlNO0051037; Tue, 19 Apr 2005 16:47:23 -0400 (EDT) (envelope-from green) Date: Tue, 19 Apr 2005 16:47:23 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050419204723.GG1157@green.homeunix.org> References: <20050415150708.GP981@green.homeunix.org> <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419161616.GF1157@green.homeunix.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 20:48:36 -0000 On Tue, Apr 19, 2005 at 12:16:16PM -0400, Brian Fundakowski Feldman wrote: > On Tue, Apr 19, 2005 at 06:09:00PM +0200, Marc Olzheim wrote: > > On Tue, Apr 19, 2005 at 06:02:58PM +0200, Marc Olzheim wrote: > > > On Tue, Apr 19, 2005 at 11:18:00AM -0400, Brian Fundakowski Feldman wrote: > > > > Does this work for you? > > > > > > ... > > > > > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/nfsclient/nfs_bio.c > > > /usr/src/sys/nfsclient/nfs_bio.c: In function `nfs_write': > > > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > > > /usr/src/sys/nfsclient/nfs_bio.c:976: error: invalid type argument of `->' > > > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > > > /usr/src/sys/nfsclient/nfs_bio.c:984: error: invalid type argument of `->' > > > *** Error code 1 > > > > That's about the BO_LOCK(vp->v_bufobj); and the BO_UNLOCK(vp->v_bufobj); > > Yeah, I get that too. I have no clue why it's doing that, I was figuring > it was just my compile setup... Okay, stupid me. This compiles. cvs diff: Diffing sys Index: sys/buf.h =================================================================== RCS file: /usr/ncvs/src/sys/sys/buf.h,v retrieving revision 1.185 diff -u -u -r1.185 buf.h --- sys/buf.h 10 Feb 2005 12:17:48 -0000 1.185 +++ sys/buf.h 19 Apr 2005 14:30:54 -0000 @@ -465,6 +465,7 @@ extern int maxswzone; /* Max KVA for swap structures */ extern int maxbcache; /* Max KVA for buffer cache */ extern int runningbufspace; +extern int hibufspace; extern int buf_maxio; /* nominal maximum I/O for buffer */ extern struct buf *buf; /* The buffer headers. */ extern char *buffers; /* The buffer contents. */ Index: sys/bufobj.h =================================================================== RCS file: /usr/ncvs/src/sys/sys/bufobj.h,v retrieving revision 1.13 diff -u -u -r1.13 bufobj.h --- sys/bufobj.h 19 Feb 2005 11:44:57 -0000 1.13 +++ sys/bufobj.h 19 Apr 2005 20:39:10 -0000 @@ -109,13 +109,13 @@ #define BO_LOCK(bo) \ do { \ - KASSERT (bo->bo_mtx != NULL, ("No lock in bufobj")); \ + KASSERT((bo)->bo_mtx != NULL, ("No lock in bufobj")); \ mtx_lock((bo)->bo_mtx); \ } while (0) #define BO_UNLOCK(bo) \ do { \ - KASSERT (bo->bo_mtx != NULL, ("No lock in bufobj")); \ + KASSERT((bo)->bo_mtx != NULL, ("No lock in bufobj")); \ mtx_unlock((bo)->bo_mtx); \ } while (0) cvs diff: Diffing kern Index: kern/vfs_bio.c =================================================================== RCS file: /usr/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.482 diff -u -u -r1.482 vfs_bio.c --- kern/vfs_bio.c 25 Mar 2005 00:20:37 -0000 1.482 +++ kern/vfs_bio.c 19 Apr 2005 14:30:54 -0000 @@ -127,7 +127,7 @@ static int lobufspace; SYSCTL_INT(_vfs, OID_AUTO, lobufspace, CTLFLAG_RD, &lobufspace, 0, "Minimum amount of buffers we want to have"); -static int hibufspace; +int hibufspace; SYSCTL_INT(_vfs, OID_AUTO, hibufspace, CTLFLAG_RD, &hibufspace, 0, "Maximum allowed value of bufspace (excluding buf_daemon)"); static int bufreusecnt; cvs diff: Diffing nfsclient Index: nfsclient/nfs_bio.c =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfs_bio.c,v retrieving revision 1.150 diff -u -u -r1.150 nfs_bio.c --- nfsclient/nfs_bio.c 18 Mar 2005 21:23:32 -0000 1.150 +++ nfsclient/nfs_bio.c 19 Apr 2005 20:38:34 -0000 @@ -844,6 +844,7 @@ struct vattr vattr; struct nfsmount *nmp = VFSTONFS(vp->v_mount); daddr_t lbn; + off_t commitleft; /* if non-zero, the amount left we may write */ int bcount; int n, on, error = 0; int haverslock = 0; @@ -873,6 +874,14 @@ */ if (ioflag & (IO_APPEND | IO_SYNC)) { if (np->n_flag & NMODIFIED) { +flush_and_restart: + /* + * Require non-blocking, synchronous writes to + * dirty files to inform the program it needs + * to fsync(2) explicitly. + */ + if (ioflag & IO_NDELAY) + return (EAGAIN); np->n_attrstamp = 0; error = nfs_vinvalbuf(vp, V_SAVE, td, 1); if (error) @@ -953,12 +962,65 @@ } biosize = vp->v_mount->mnt_stat.f_iosize; + commitleft = 0; + /* + * If there are possible modifications, find all of this file's + * B_NEEDCOMMIT buffers. If our writes would exceed the local + * maximum per-file write commit size when combined with those, + * we decide to flush and/or do a short write. + */ + if ((ioflag & (IO_SYNC | IO_INVAL)) != (IO_SYNC | IO_INVAL)) { + commitleft = nmp->nm_wcommitsize; + if (np->n_flag & NMODIFIED) { + int wouldcommit = 0; + BO_LOCK(&vp->v_bufobj); + if (vp->v_bufobj.bo_dirty.bv_cnt != 0) { + TAILQ_FOREACH(bp, &vp->v_bufobj.bo_dirty.bv_hd, + b_bobufs) { + if (bp->b_flags & B_NEEDCOMMIT) + wouldcommit += bp->b_bcount; + } + } + BO_UNLOCK(&vp->v_bufobj); + /* + * Since we're not operating synchronously and + * bypassing the buffer cache, we are in a commit + * and holding all of these buffers whether + * transmitted or not. If not limited, this + * will lead to the buffer cache deadlocking, + * as no one else can flush our uncommitted buffers. + */ + wouldcommit += uio->uio_resid; + /* + * If we would initially exceed the maximum + * outstanding write commit size, flush and restart. + */ + if (wouldcommit > commitleft) { + if (haverslock) { + nfs_rsunlock(np, td); + haverslock = 0; + } + goto flush_and_restart; + } + } else { + /* + * With no outstanding commits, we are limited only + * by commitleft as to how far we can go. + */ + } + } do { nfsstats.biocache_writes++; lbn = uio->uio_offset / biosize; on = uio->uio_offset & (biosize-1); n = min((unsigned)(biosize - on), uio->uio_resid); + /* Always allow at least the very first write. */ + if (commitleft > 0) { + commitleft -= n; + if (commitleft == 0) + commitleft = -1; + } again: /* * Handle direct append and file extension cases, calculate @@ -1146,10 +1208,21 @@ } else { bdwrite(bp); } - } while (uio->uio_resid > 0 && n > 0); + } while (uio->uio_resid > 0 && n > 0 && commitleft >= 0); - if (haverslock) + if (haverslock) { + haverslock = 0; nfs_rsunlock(np, td); + } + + /* + * On the off chance that we're trying to do a very large + * and non-atomic write, go ahead and let that just continue + * within the same call after flushing out what's been written. + */ + if (error == 0 && uio->uio_resid > 0 && n > 0 && commitleft < 0 && + !(ioflag & IO_UNIT)) + goto flush_and_restart; return (error); } Index: nfsclient/nfs_vfsops.c =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfs_vfsops.c,v retrieving revision 1.172 diff -u -u -r1.172 nfs_vfsops.c --- nfsclient/nfs_vfsops.c 24 Mar 2005 07:37:22 -0000 1.172 +++ nfsclient/nfs_vfsops.c 19 Apr 2005 14:32:19 -0000 @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include #include @@ -626,6 +628,12 @@ else nmp->nm_readahead = NFS_MAXRAHEAD; } + if ((argp->flags & NFSMNT_WCOMMITSIZE) && argp->wcommitsize >= 0) { + if (argp->wcommitsize < nmp->nm_wsize) + nmp->nm_wcommitsize = nmp->nm_wsize; + else + nmp->nm_wcommitsize = argp->wcommitsize; + } if ((argp->flags & NFSMNT_DEADTHRESH) && argp->deadthresh >= 0) { if (argp->deadthresh <= NFS_MAXDEADTHRESH) nmp->nm_deadthresh = argp->deadthresh; @@ -808,6 +816,7 @@ nmp->nm_wsize = NFS_WSIZE; nmp->nm_rsize = NFS_RSIZE; } + nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); nmp->nm_readdirsize = NFS_READDIRSIZE; nmp->nm_numgrps = NFS_MAXGRPS; nmp->nm_readahead = NFS_DEFRAHEAD; Index: nfsclient/nfsargs.h =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfsargs.h,v retrieving revision 1.67 diff -u -u -r1.67 nfsargs.h --- nfsclient/nfsargs.h 7 Jan 2005 01:45:51 -0000 1.67 +++ nfsclient/nfsargs.h 19 Apr 2005 14:30:54 -0000 @@ -56,7 +56,7 @@ int retrans; /* times to retry send */ int maxgrouplist; /* Max. size of group list */ int readahead; /* # of blocks to readahead */ - int __pad1; /* was "leaseterm" */ + int wcommitsize; /* Max. write commit size in bytes */ int deadthresh; /* Retrans threshold */ char *hostname; /* server's name */ int acregmin; /* cache attrs for reg files min time */ @@ -80,7 +80,7 @@ #define NFSMNT_NFSV3 0x00000200 /* Use NFS Version 3 protocol */ /* 0x400 free, was NFSMNT_KERB */ #define NFSMNT_DUMBTIMR 0x00000800 /* Don't estimate rtt dynamically */ -/* 0x1000 free, was NFSMNT_LEASETERM */ +#define NFSMNT_WCOMMITSIZE 0x00001000 /* set max write commit size */ #define NFSMNT_READAHEAD 0x00002000 /* set read ahead */ #define NFSMNT_DEADTHRESH 0x00004000 /* set dead server retry thresh */ #define NFSMNT_RESVPORT 0x00008000 /* Allocate a reserved port */ Index: nfsclient/nfsmount.h =================================================================== RCS file: /usr/ncvs/src/sys/nfsclient/nfsmount.h,v retrieving revision 1.29 diff -u -u -r1.29 nfsmount.h --- nfsclient/nfsmount.h 7 Jan 2005 01:45:51 -0000 1.29 +++ nfsclient/nfsmount.h 19 Apr 2005 14:30:54 -0000 @@ -74,6 +74,7 @@ int nm_wsize; /* Max size of write rpc */ int nm_readdirsize; /* Size of a readdir rpc */ int nm_readahead; /* Num. of blocks to readahead */ + int nm_wcommitsize; /* Max size of commit for write */ int nm_acdirmin; /* Directory attr cache min lifetime */ int nm_acdirmax; /* Directory attr cache max lifetime */ int nm_acregmin; /* Reg file attr cache min lifetime */ -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 21:15:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 136A316A4CE; Tue, 19 Apr 2005 21:15:23 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387F743D53; Tue, 19 Apr 2005 21:15:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JLFKBr045482; Tue, 19 Apr 2005 17:15:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3JLFdK0004127; Tue, 19 Apr 2005 17:15:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9B72E7306E; Tue, 19 Apr 2005 17:15:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050419211520.9B72E7306E@freebsd-current.sentex.ca> Date: Tue, 19 Apr 2005 17:15:20 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 21:15:23 -0000 TB --- 2005-04-19 20:00:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-19 20:00:22 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-04-19 20:00:22 - checking out the source tree TB --- 2005-04-19 20:00:22 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-04-19 20:00:22 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-19 20:07:07 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-19 20:07:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-19 20:07:07 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-19 21:14:02 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-19 21:14:02 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-04-19 21:14:02 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 19 21:14:03 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] machine -> /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/include rm -f .depend GPATH GRTAGS GSYMS GTAGS rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c In file included from /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c:40: @/sys/pmc.h:1120:2: #error Unsupported PMC architecture. /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/hwpmc/../../hwpmc/hwpmc_mod.c:53:30: machine/pmc_mdep.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/hwpmc. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-04-19 21:15:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-19 21:15:20 - ERROR: failed to build generic kernel TB --- 2005-04-19 21:15:20 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 22:30:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B31A16A4CE; Tue, 19 Apr 2005 22:30:19 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BF3543D58; Tue, 19 Apr 2005 22:30:16 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j3JMUUsM021285; Tue, 19 Apr 2005 18:30:30 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-ports@freebsd.org Date: Tue, 19 Apr 2005 18:30:12 -0400 User-Agent: KMail/1.6.2 References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A529.6090004@freebsd.org> <4261A7BE.3070606@freebsd.org> In-Reply-To: <4261A7BE.3070606@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504191830.12579.jkim@niksun.com> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on anuket.mj.niksun.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: David Xu Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 22:30:19 -0000 On Saturday 16 April 2005 08:03 pm, David Xu wrote: > David Xu wrote: > > With newest -CURRENT kernel, I can not shutdown gnome from > > panel, did anyone encounter the problem ? > > > > David Xu > > Here is some gdb outputs, it seems thread 2 stuck in connect(), > is UNIX socket broken ? I am experiencing the same problem. I rebuilt whole system from world and ports, tried different threading libraries, kernel options, removed gnome configurations from home directory, etc. but nothing helped. :-( I am using Xfce4 for now... [Note: CC'ing current@.] Jung-uk Kim > Script started on Sun Apr 17 07:58:46 2005 > davidxu@alona:/home/davidxu> gdb `which gnome-panel` 738 > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are welcome to change it and/or distribute copies of it > under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. This GDB was configured as "amd64-marcel-freebsd"...(no > debugging symbols found)... > Attaching to program: /usr/X11R6/bin/gnome-panel, process 738 > Reading symbols from /usr/X11R6/lib/libgnome-desktop-2.so.4...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnome-desktop-2.so.4 > Reading symbols from /usr/X11R6/lib/libgnomeui-2.so.1000...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnomeui-2.so.1000 > Reading symbols from /usr/X11R6/lib/libSM.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libSM.so.6 > Reading symbols from /usr/X11R6/lib/libICE.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libICE.so.6 > Reading symbols from > /usr/X11R6/lib/libstartup-notification-1.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libstartup-notification-1.so.0 > Reading symbols from /usr/X11R6/lib/libbonoboui-2.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libbonoboui-2.so.0 > Reading symbols from /usr/X11R6/lib/libgnomecanvas-2.so.1000...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnomecanvas-2.so.1000 > Reading symbols from /usr/X11R6/lib/libgnome-2.so.1000...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnome-2.so.1000 > Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 > Reading symbols from /usr/X11R6/lib/libpangoft2-1.0.so.800...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libpangoft2-1.0.so.800 > Reading symbols from /usr/X11R6/lib/libgnomevfs-2.so.1000...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnomevfs-2.so.1000 > Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libbonobo-2.so.0 > Reading symbols from /usr/local/lib/libbonobo-activation.so.4...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 > Reading symbols from /usr/X11R6/lib/libglade-2.0.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libglade-2.0.so.0 > Reading symbols from /usr/X11R6/lib/libgtk-x11-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgtk-x11-2.0.so.600 > Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libxml2.so.5 > Reading symbols from /usr/X11R6/lib/libgdk-x11-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgdk-x11-2.0.so.600 > Reading symbols from /usr/X11R6/lib/libXrandr.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXrandr.so.2 > Reading symbols from /usr/X11R6/lib/libXi.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXi.so.6 > Reading symbols from /usr/X11R6/lib/libXinerama.so.1...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXinerama.so.1 > Reading symbols from /usr/X11R6/lib/libXfixes.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXfixes.so.3 > Reading symbols from /usr/X11R6/lib/libXcursor.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXcursor.so.1 > Reading symbols from /usr/local/lib/libatk-1.0.so.901...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libatk-1.0.so.901 > Reading symbols from /usr/X11R6/lib/libgdk_pixbuf-2.0.so.600...(no > debgging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgdk_pixbuf-2.0.so.600 > Reading symbols from /usr/X11R6/lib/libpangoxft-1.0.so.800...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libpangoxft-1.0.so.800 > Reading symbols from /usr/X11R6/lib/libXft.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXft.so.2 > Reading symbols from /usr/local/lib/libfreetype.so.9...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libfreetype.so.9 > Reading symbols from /lib/libz.so.2...(no debugging symbols > found)...done. Loaded symbols for /lib/libz.so.2 > Reading symbols from /usr/X11R6/lib/libXrender.so.1...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXrender.so.1 > Reading symbols from /usr/X11R6/lib/libXext.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libXext.so.6 > Reading symbols from /usr/X11R6/lib/libfontconfig.so.1...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libfontconfig.so.1 > Reading symbols from /usr/X11R6/lib/libpangox-1.0.so.800...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libpangox-1.0.so.800 > Reading symbols from /usr/X11R6/lib/libX11.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libX11.so.6 > Reading symbols from /usr/X11R6/lib/libpango-1.0.so.800...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libpango-1.0.so.800 > Reading symbols from /usr/local/lib/libgobject-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgobject-2.0.so.600 > Reading symbols from /usr/X11R6/lib/libgconf-2.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgconf-2.so.5 > Reading symbols from /usr/local/lib/libORBit-2.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libORBit-2.so.0 > Reading symbols from /lib/libm.so.3...(no debugging symbols > found)...done. Loaded symbols for /lib/libm.so.3 > Reading symbols from /usr/local/lib/libgmodule-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgmodule-2.0.so.600 > Reading symbols from /usr/local/lib/libgthread-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libgthread-2.0.so.600 > Reading symbols from /usr/X11R6/lib/libgnome-menu.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnome-menu.so.0 > Reading symbols from /usr/local/lib/libglib-2.0.so.600...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libglib-2.0.so.600 > Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpopt.so.0 > Reading symbols from /usr/lib/libthr.so.1...(no debugging symbols > found)...done. > [New Thread 0x853400 (LWP 100100)] > [New Thread 0x57c000 (LWP 100124)] > Loaded symbols for /usr/lib/libthr.so.1 > Reading symbols from /lib/libc.so.6...(no debugging symbols > found)...done. Loaded symbols for /lib/libc.so.6 > Reading symbols from /usr/local/lib/libintl.so.6...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libintl.so.6 > Reading symbols from /usr/X11R6/lib/libgnome-keyring.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/X11R6/lib/libgnome-keyring.so.0 > Reading symbols from /usr/local/lib/libjpeg.so.9...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libjpeg.so.9 > Reading symbols from /usr/local/lib/libesd.so.2...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libesd.so.2 > Reading symbols from /usr/local/lib/libaudiofile.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libaudiofile.so.0 > Reading symbols from /usr/lib/libssl.so.3...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libssl.so.3 > Reading symbos from /lib/libcrypto.so.3...(no debugging symbols > found)...done. > Loaded symbols for /lib/libcrypto.so.3 > Reading symbols from /usr/local/lib/libORBitCosNaming-2.so.0...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 > Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libexpat.so.5 > Reading symbols from > /usr/X11R6/lib/X11/locale/lib/common/xlocale.so.2...(no debugging > symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/X11/locale/lib/common/xlocale.so.2 Reading symbols > from > /usr/X11R6/lib/X11/locale/lib/common/xlibi18n.so.2...(no debugging > symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/X11/locale/lib/common/xlibi18n.so.2 Reading symbols > from > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libthinice.so...(no debugging > symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libthinice.so Reading symbols > from > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libredmond95.so...(no > debugging symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libredmond95.so Reading > symbols from > /usr/X11R6/lib/pango/1.4.0/modules/pango-basic-fc.so...(no > debugging symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/pango/1.4.0/modules/pango-basic-fc.so Reading > symbols from > /usr/X11R6/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so...(no > debugging symbols found)...done. > Loaded symbols for > /usr/X11R6/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so > Reading symbols from /usr/local/lib/libpng.so.5...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libpng.so.5 > Reading symbols from > /usr/local/lib/bonobo/monikers/libmoniker_std_2.so...(no debugging > symbols found)...done. > Loaded symbols for > /usr/local/lib/bonobo/monikers/libmoniker_std_2.so Reading symbols > from > /usr/X11R6/lib/gnome-vfs-2.0/modules/libfile.so...(no debugging > symbols found)...done. > Loaded symbols for /usr/X11R6/lib/gnome-vfs-2.0/modules/libfile.so > Reading symbols from /usr/local/lib/libfam.so.0...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libfam.so.0 > Reading symbols from /usr/lib/libstdc++.so.4...(no debugging > symbols found)...done. > Loaded symbols for /usr/lib/libstdc++.so.4 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > [Switching to Thread 0x853400 (LWP 100100)] > 0x00000008040a935c in poll () from /lib/libc.so.6 > (gdb) info threads > 2 Thread 0x57c000 (LWP 100124) 0x00000008040a9a1c in connect () > from /lib/libc.so.6 > * 1 Thread 0x853400 (LWP 100100) 0x00000008040a935c in poll () > from /lib/libc.so.6 > (gdb) thread 2 > [Switching to thread 2 (Thread 0x57c000 (LWP 100124))]#0 > 0x00000008040a9a1c in connect () from /lib/libc.so.6 > (gdb) bt > #0 0x00000008040a9a1c in connect () from /lib/libc.so.6 > #1 0x0000000803f4a823 in connect () from /usr/lib/libthr.so.1 > #2 0x000000080458d7b3 in esd_connect_unix () from > /usr/local/lib/libesd.so.2 > #3 0x000000080458dbeb in esd_open_sound () from > /usr/local/lib/libesd.so.2 #4 0x0000000800f13c82 in > gnome_config_set_sync_handler () from > /usr/X11R6/lib/libgnome-2.so.1000 > #5 0x0000000800f14139 in gnome_sound_connection_get () > from /usr/X11R6/lib/libgnome-2.so.1000 > #6 0x0000000800f1459e in gnome_triggers_add_trigger () > from /usr/X11R6/lib/libgnome-2.so.1000 > #7 0x0000000800f146e8 in gnome_triggers_vdo () > from /usr/X11R6/lib/libgnome-2.so.1000 > #8 0x0000000800f149ba in gnome_triggers_do () > from /usr/X11R6/lib/libgnome-2.so.1000 > #9 0x0000000800814c81 in gnome_client_request_save () > from /usr/X11R6/lib/libgnomeui-2.so.1000 > #10 0x0000000000441622 in panel_init_stock_icons_and_items () > #11 0x00000008032b2fcf in g_closure_invoke () > from /usr/local/lib/libgobject-2.0.so.600 > #12 0x00000008032c714e in g_signal_has_handler_pending () > from /usr/local/lib/libgobject-2.0.so.600 > #13 0x00000008032c82cb in g_signal_emit_valist () > from /usr/local/lib/libgobject-2.0.so.600 > #14 0x00000008032c86a3 in _signal_emit () > ---Type to continue, or q to quit--- > from /usr/local/lib/libgobject-2.0.so.600 > #15 0x000000080196e852 in gtk_widget_activate () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #16 0x000000080189fbf0 in gtk_menu_shell_activate_item () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #17 0x000000080189fefb in gtk_menu_shell_activate_item () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #18 0x0000000801891576 in gtk_marshal_VOID__UINT_STRING () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #19 0x00000008032b2fcf in g_closure_invoke () > from /usr/local/lib/libgobject-2.0.so.600 > #20 0x00000008032c6d39 in g_signal_has_handler_pending () > from /usr/local/lib/libgobject-2.0.so.600 > #21 0x00000008032c8001 in g_signal_emit_valist () > from /usr/local/lib/libgobject-2.0.so.600 > #22 0x00000008032c86a3 in g_signal_emit () > from /usr/local/lib/libgobject-2.0.so.600 > #23 0x000000080196e9b0 in gtk_widget_activate () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #24 0x000000080188f961 in gtk_propagate_event () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #25 0x000000080188fc9c in gtk_main_do_event () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #26 0x0000000801dda5a0 in gdk_event_get_graphics_expose () > ---Type to continue, or q to quit--- > from /usr/X11R6/lib/libgdk-x11-2.0.so.600 > #27 0x0000000803ae75bd in g_main_context_dispatch () > from /usr/local/lib/libglib-2.0.so.600 > #28 0x0000000803ae923c in g_main_context_acquire () > from /usr/local/lib/libglib-2.0.so.600 > #29 0x0000000803ae95c9 in g_main_loop_run () > from /usr/local/lib/libglib-2.0.so.600 > #30 0x000000080188f181 in gtk_main () > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > #31 0x000000000042275e in main () > (gdb) info thread > * 2 Thread 0x57c000 (LWP 100124) 0x00000008040a9a1c in connect () > from /lib/libc.so.6 > 1 Thread 0x853400 (LWP 100100) 0x00000008040a935c in poll () > from /lib/libc.so.6 > (gdb) therad rread 1 > [Switching to thread 1 (Thread 0x853400 (LWP 100100))]#0 > 0x00000008040a935c in poll () from /lib/libc.so.6 > (gdb) bt > #0 0x00000008040a935c in poll () from /lib/libc.so.6 > #1 0x0000000803f4adb5 in poll () from /usr/lib/libthr.so.1 > #2 0x0000000803ae91ce in g_main_context_acquire () > from /usr/local/lib/libglib-2.0.so.600 > #3 0x0000000803ae95c9 in g_main_loop_run () > from /usr/local/lib/libglib-2.0.so.600 > #4 0x00000008035648f0 in link_io_thread_fn () > from /usr/local/lib/libORBit-2.so.0 > #5 0x0000000803b01842 in g_static_private_free () > from /usr/local/lib/libglib-2.0.so.600 > #6 0x0000000803f5392c in pthread_create () from > /usr/lib/libthr.so.1 #7 0x000000080409afe4 in makecontext () from > /lib/libc.so.6 #8 0x0000000000000000 in ?? () > #9 0x0000000000853400 in ?? () > #10 0x0000000000000000 in ?? () > #11 0x0000000000000000 in ?? () > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffffbff000: Bad address. > (gdb) detach > Detaching from program: /usr/X11R6/bin/gnome-panel, process 738 > (gdb) quit > davidxu@alona:/home/davidxu> exit > > exit > > Script done on Sun Apr 17 07:59:25 2005 From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 22:52:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B5816A4CE; Tue, 19 Apr 2005 22:52:06 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F5943D55; Tue, 19 Apr 2005 22:52:06 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Tue, 19 Apr 2005 15:52:05 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 22C0D5D07; Tue, 19 Apr 2005 15:52:05 -0700 (PDT) To: Jung-uk Kim In-reply-to: Your message of "Tue, 19 Apr 2005 18:30:12 EDT." <200504191830.12579.jkim@niksun.com> Date: Tue, 19 Apr 2005 15:52:05 -0700 From: "Kevin Oberman" Message-Id: <20050419225205.22C0D5D07@ptavv.es.net> cc: freebsd-current@freebsd.org cc: David Xu cc: freebsd-ports@freebsd.org Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 22:52:06 -0000 > From: Jung-uk Kim > Date: Tue, 19 Apr 2005 18:30:12 -0400 > Sender: owner-freebsd-current@freebsd.org > > On Saturday 16 April 2005 08:03 pm, David Xu wrote: > > David Xu wrote: > > > With newest -CURRENT kernel, I can not shutdown gnome from > > > panel, did anyone encounter the problem ? > > > > > > David Xu > > > > Here is some gdb outputs, it seems thread 2 stuck in connect(), > > is UNIX socket broken ? > > I am experiencing the same problem. I rebuilt whole system from world > and ports, tried different threading libraries, kernel options, > removed gnome configurations from home directory, etc. but nothing > helped. :-( I am using Xfce4 for now... Just a "me too" (TM-AOL). In my case I see one application, gkrellm, locking up things. It is stuck in a run state (literally Rs), but is consuming almost no CPU and can't be killed. kill-9 is simply ignored. I can only get out of gnome with CRTL-ALT-BS and, when I shout down the system, I am notified that one or more processes can't be killed. I'm sure that it is referring to gkrellm. The problem started sometime after March 31. I have backed up to April 5 and I am still seeing the problem. I will continue to try to track down exactly when it started as time permits. Is this the same problem? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 22:56:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7B92816A4CF; Tue, 19 Apr 2005 22:56:40 +0000 (GMT) To: current@freebsd.org Date: Tue, 19 Apr 2005 22:56:40 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050419225640.7B92816A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Subject: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 22:56:40 -0000 For a while now I've been thinking about streamlining the process of installing NDIS drivers, mainly so that people no longer have to compile if_ndis.ko every time. After no small amount of head scratching, I've finally come up with a way to do it. There are a few aesthetic details left to work out though, for which I thought I'd solicit some opinions. As it stands now, you have to go through the following steps to load a new NDIS driver: - Find the .SYS and .INF files for your card - Use ndiscvt(8) to convert them into an ndis_driver_data.h file - Copy this file to /sys/modules/if_ndis - Compile if_ndis.ko The main problems with this are: - if_ndis.ko can't be pre-compiled and shipped with the system - the kernel source must be installed - using ndiscvt(8) is a little confusing The new system I've cooked up works like this: - ndis.ko and if_ndis.ko are both pre-built for you. - A new installation screipt, tentatively named wintobsd.sh, and a small C file, windrv_stub.c are installed with the base OS. - The wintobsd.sh script is interactive and prompts you to enter the path for both your .INF and .SYS files. - If necessary, the script will run iconv(1) on .INF files that are actually in unicode format (people often forget to do this and then wonder why ndiscvt(8) doesn't work) - The script will run ndiscvt(8), but use the -O option to convert the .SYS file directly into a .o file (via the magic of objcopy(1)) and produce a stripped down .h file with just the device ID and registry info in it (rather than the usual giant .h file with an encoded byte array containing the .SYS image). - Lastly, the script will compile the windrv_stub.c file and link it against the converted .o file, producing a .ko file that can be kldloaded into the system. - Optionally, the script can also produce a non-shared .o file that can be statically linked into the kernel, for those who need/want static kernel images. The objcopy(1) trick basically produces an ELF file that has the Windows .SYS file encapsulated with in it. Two symbols are created to denote the start end end of the image so that it can be loaded later. The windrv_stub.o module linked with the Windows image provides a small FreeBSD modevent handler that hooks the driver into Project Evil and eventually causes a bus-reprobe. This means that all you have to do is kldload this one module into the kernel, and presto! a new ndisX networking interface appears. The end result is that installing a Windows driver should be as simple as: - run the script - give it your foo.inf and foo.sys files when it asks you - it spits out a foo_sys.ko module and you kldload it - the end You still end up needing the C compiler, objcopy, ndiscvt and (optionally) iconv, but the script automates the use of all these tooks and explains to the user what's going on while it's working. Anyway. The things I have yet to determine are: - Where should windrv_stub.c ultimately be installed? I'm thinking it should go in /usr/share/misc. - What should the script be called? wintobsd.sh sounds kind of lame. Any suggestions or comments on my mad scheme would be welcome. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 23:16:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D34BF16A4CE; Tue, 19 Apr 2005 23:16:30 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6969043D45; Tue, 19 Apr 2005 23:16:30 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j3JNGd5A022225; Tue, 19 Apr 2005 19:16:40 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-current@freebsd.org Date: Tue, 19 Apr 2005 19:16:21 -0400 User-Agent: KMail/1.6.2 References: <20050419225205.22C0D5D07@ptavv.es.net> In-Reply-To: <20050419225205.22C0D5D07@ptavv.es.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200504191916.21676.jkim@niksun.com> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on anuket.mj.niksun.com X-Virus-Status: Clean cc: David Xu cc: freebsd-ports@freebsd.org Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 23:16:31 -0000 On Tuesday 19 April 2005 06:52 pm, Kevin Oberman wrote: > > From: Jung-uk Kim > > Date: Tue, 19 Apr 2005 18:30:12 -0400 > > Sender: owner-freebsd-current@freebsd.org > > > > On Saturday 16 April 2005 08:03 pm, David Xu wrote: > > > David Xu wrote: > > > > With newest -CURRENT kernel, I can not shutdown gnome from > > > > panel, did anyone encounter the problem ? > > > > > > > > David Xu > > > > > > Here is some gdb outputs, it seems thread 2 stuck in connect(), > > > is UNIX socket broken ? > > > > I am experiencing the same problem. I rebuilt whole system from > > world and ports, tried different threading libraries, kernel > > options, removed gnome configurations from home directory, etc. > > but nothing helped. :-( I am using Xfce4 for now... > > Just a "me too" (TM-AOL). In my case I see one application, > gkrellm, locking up things. It is stuck in a run state (literally > Rs), but is consuming almost no CPU and can't be killed. kill-9 is > simply ignored. > > I can only get out of gnome with CRTL-ALT-BS and, when I shout down > the system, I am notified that one or more processes can't be > killed. I'm sure that it is referring to gkrellm. > > The problem started sometime after March 31. I have backed up to > April 5 and I am still seeing the problem. I will continue to try > to track down exactly when it started as time permits. > > Is this the same problem? I don't know but this problem showed up very recently, say last week. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 23:19:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D65F616A4CE; Tue, 19 Apr 2005 23:19:40 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E3843D48; Tue, 19 Apr 2005 23:19:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3JNJdxd027608; Tue, 19 Apr 2005 19:19:39 -0400 (EDT) Date: Tue, 19 Apr 2005 19:19:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bill Paul In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 23:19:40 -0000 On Tue, 19 Apr 2005, Bill Paul wrote: > [ ... ] > The end result is that installing a Windows driver should be as simple > as: > > - run the script > - give it your foo.inf and foo.sys files when it asks you > - it spits out a foo_sys.ko module and you kldload it > - the end Sounds great. > - What should the script be called? wintobsd.sh sounds kind of lame. ndis2ko, evil2ko, evilcvt_ndis, PExorcise, koify_ndis, ndisify, pen[d]isify -- DE From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 23:22:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E697C16A4CF; Tue, 19 Apr 2005 23:22:22 +0000 (GMT) In-Reply-To: <20050419160747.B65507@xorpc.icir.org> from Luigi Rizzo at "Apr 19, 2005 04:07:47 pm" To: rizzo@icir.org (Luigi Rizzo) Date: Tue, 19 Apr 2005 23:22:22 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050419232222.E697C16A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 23:22:23 -0000 > interesting description. > I just wonder if you could compile windrv_stub.c once for all, > providing enough "data" space to store the image, use a magic > string to detect the beginning of the relevant data areas, > and then "dd" the converted .sys image and .INF entries into the .ko > file in the same way as it is done to dump filesystem images into > the PicoBSD kernels. The problem is that windrv_stub.c contains some module/driver/version declaration macros, and in order to avoid collisions between driver modules, the names must be unique. The script figures out a unique name based on the .sys file name and passes that to the stub as a preprocessor macro via cc -D at compile time. Also, part of the process involves extracting the device ID and registry info from the .INF file and packaging it up with the .ko file. The simplest way to do this is just compile it as before, only now it takes much less work because you're not building a gigantic byte array too. > Last not least, given that all you need to do in the end is run > the script, it could well be called ndiscvt and replace the > old utility altogether... and know the location of the stub > file itself, if necessary at all. Well, ultimately I'm hoping this will useful for more than just NDIS drivers, so I'm trying to avoid using 'ndis' too much to describe stuff that should be a little more generic. -Bill > cheers > luigi > > On Tue, Apr 19, 2005 at 10:56:40PM +0000, Bill Paul wrote: > > > > For a while now I've been thinking about streamlining the process of > > installing NDIS drivers, mainly so that people no longer have to compile > > if_ndis.ko every time. After no small amount of head scratching, I've > > finally come up with a way to do it. There are a few aesthetic details > > left to work out though, for which I thought I'd solicit some opinions. > > > > As it stands now, you have to go through the following steps to > > load a new NDIS driver: > > > > - Find the .SYS and .INF files for your card > > - Use ndiscvt(8) to convert them into an ndis_driver_data.h file > > - Copy this file to /sys/modules/if_ndis > > - Compile if_ndis.ko > > > > The main problems with this are: > > > > - if_ndis.ko can't be pre-compiled and shipped with the system > > - the kernel source must be installed > > - using ndiscvt(8) is a little confusing > > > > The new system I've cooked up works like this: > > > > - ndis.ko and if_ndis.ko are both pre-built for you. > > - A new installation screipt, tentatively named wintobsd.sh, and > > a small C file, windrv_stub.c are installed with the base OS. > > - The wintobsd.sh script is interactive and prompts you to enter > > the path for both your .INF and .SYS files. > > - If necessary, the script will run iconv(1) on .INF files that > > are actually in unicode format (people often forget to do this > > and then wonder why ndiscvt(8) doesn't work) > > - The script will run ndiscvt(8), but use the -O option to convert > > the .SYS file directly into a .o file (via the magic of objcopy(1)) > > and produce a stripped down .h file with just the device ID and > > registry info in it (rather than the usual giant .h file with > > an encoded byte array containing the .SYS image). > > - Lastly, the script will compile the windrv_stub.c file and link > > it against the converted .o file, producing a .ko file that > > can be kldloaded into the system. > > - Optionally, the script can also produce a non-shared .o file that > > can be statically linked into the kernel, for those who need/want > > static kernel images. > > > > The objcopy(1) trick basically produces an ELF file that has the > > Windows .SYS file encapsulated with in it. Two symbols are created > > to denote the start end end of the image so that it can be loaded later. > > The windrv_stub.o module linked with the Windows image provides a > > small FreeBSD modevent handler that hooks the driver into Project > > Evil and eventually causes a bus-reprobe. This means that all you > > have to do is kldload this one module into the kernel, and presto! > > a new ndisX networking interface appears. > > > > The end result is that installing a Windows driver should be as simple > > as: > > > > - run the script > > - give it your foo.inf and foo.sys files when it asks you > > - it spits out a foo_sys.ko module and you kldload it > > - the end > > > > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > > iconv, but the script automates the use of all these tooks and explains > > to the user what's going on while it's working. > > > > Anyway. The things I have yet to determine are: > > > > - Where should windrv_stub.c ultimately be installed? I'm thinking it > > should go in /usr/share/misc. > > > > - What should the script be called? wintobsd.sh sounds kind of lame. > > > > Any suggestions or comments on my mad scheme would be welcome. > > > > -Bill > > > > -- > > ============================================================================= > > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > > wpaul@windriver.com | Wind River Systems > > ============================================================================= > > you're just BEGGING to face the moose > > ============================================================================= > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 00:12:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC28016A4CE; Wed, 20 Apr 2005 00:12:02 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF83C43D49; Wed, 20 Apr 2005 00:12:01 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j3K0CF8l023032; Tue, 19 Apr 2005 20:12:16 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-current@freebsd.org Date: Tue, 19 Apr 2005 20:11:57 -0400 User-Agent: KMail/1.6.2 References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A7BE.3070606@freebsd.org> <200504191830.12579.jkim@niksun.com> In-Reply-To: <200504191830.12579.jkim@niksun.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200504192011.57723.jkim@niksun.com> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on anuket.mj.niksun.com X-Virus-Status: Clean cc: "Matthew N. Dodd" cc: David Xu cc: freebsd-ports@freebsd.org Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 00:12:03 -0000 On Tuesday 19 April 2005 06:30 pm, Jung-uk Kim wrote: > On Saturday 16 April 2005 08:03 pm, David Xu wrote: > > David Xu wrote: > > > With newest -CURRENT kernel, I can not shutdown gnome from > > > panel, did anyone encounter the problem ? > > > > > > David Xu > > > > Here is some gdb outputs, it seems thread 2 stuck in connect(), > > is UNIX socket broken ? > > I am experiencing the same problem. I rebuilt whole system from > world and ports, tried different threading libraries, kernel > options, removed gnome configurations from home directory, etc. but > nothing helped. :-( I am using Xfce4 for now... Reverting the following commit fixed the problem: http://docs.freebsd.org/cgi/mid.cgi?200504130001.j3D01kuD081602 Jung-uk Kim > [Note: CC'ing current@.] > > Jung-uk Kim > > > Script started on Sun Apr 17 07:58:46 2005 > > davidxu@alona:/home/davidxu> gdb `which gnome-panel` 738 > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, > > and you are welcome to change it and/or distribute copies of it > > under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" > > for details. This GDB was configured as > > "amd64-marcel-freebsd"...(no debugging symbols found)... > > Attaching to program: /usr/X11R6/bin/gnome-panel, process 738 > > Reading symbols from /usr/X11R6/lib/libgnome-desktop-2.so.4...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnome-desktop-2.so.4 > > Reading symbols from /usr/X11R6/lib/libgnomeui-2.so.1000...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnomeui-2.so.1000 > > Reading symbols from /usr/X11R6/lib/libSM.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libSM.so.6 > > Reading symbols from /usr/X11R6/lib/libICE.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libICE.so.6 > > Reading symbols from > > /usr/X11R6/lib/libstartup-notification-1.so.0...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libstartup-notification-1.so.0 > > Reading symbols from /usr/X11R6/lib/libbonoboui-2.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libbonoboui-2.so.0 > > Reading symbols from > > /usr/X11R6/lib/libgnomecanvas-2.so.1000...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnomecanvas-2.so.1000 > > Reading symbols from /usr/X11R6/lib/libgnome-2.so.1000...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnome-2.so.1000 > > Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 > > Reading symbols from /usr/X11R6/lib/libpangoft2-1.0.so.800...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libpangoft2-1.0.so.800 > > Reading symbols from /usr/X11R6/lib/libgnomevfs-2.so.1000...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnomevfs-2.so.1000 > > Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libbonobo-2.so.0 > > Reading symbols from > > /usr/local/lib/libbonobo-activation.so.4...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 > > Reading symbols from /usr/X11R6/lib/libglade-2.0.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libglade-2.0.so.0 > > Reading symbols from /usr/X11R6/lib/libgtk-x11-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libxml2.so.5 > > Reading symbols from /usr/X11R6/lib/libgdk-x11-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgdk-x11-2.0.so.600 > > Reading symbols from /usr/X11R6/lib/libXrandr.so.2...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXrandr.so.2 > > Reading symbols from /usr/X11R6/lib/libXi.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXi.so.6 > > Reading symbols from /usr/X11R6/lib/libXinerama.so.1...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXinerama.so.1 > > Reading symbols from /usr/X11R6/lib/libXfixes.so.3...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXfixes.so.3 > > Reading symbols from /usr/X11R6/lib/libXcursor.so.1...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXcursor.so.1 > > Reading symbols from /usr/local/lib/libatk-1.0.so.901...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libatk-1.0.so.901 > > Reading symbols from > > /usr/X11R6/lib/libgdk_pixbuf-2.0.so.600...(no debgging symbols > > found)...done. > > Loaded symbols for /usr/X11R6/lib/libgdk_pixbuf-2.0.so.600 > > Reading symbols from /usr/X11R6/lib/libpangoxft-1.0.so.800...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libpangoxft-1.0.so.800 > > Reading symbols from /usr/X11R6/lib/libXft.so.2...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXft.so.2 > > Reading symbols from /usr/local/lib/libfreetype.so.9...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libfreetype.so.9 > > Reading symbols from /lib/libz.so.2...(no debugging symbols > > found)...done. Loaded symbols for /lib/libz.so.2 > > Reading symbols from /usr/X11R6/lib/libXrender.so.1...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXrender.so.1 > > Reading symbols from /usr/X11R6/lib/libXext.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libXext.so.6 > > Reading symbols from /usr/X11R6/lib/libfontconfig.so.1...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libfontconfig.so.1 > > Reading symbols from /usr/X11R6/lib/libpangox-1.0.so.800...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libpangox-1.0.so.800 > > Reading symbols from /usr/X11R6/lib/libX11.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libX11.so.6 > > Reading symbols from /usr/X11R6/lib/libpango-1.0.so.800...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libpango-1.0.so.800 > > Reading symbols from /usr/local/lib/libgobject-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libgobject-2.0.so.600 > > Reading symbols from /usr/X11R6/lib/libgconf-2.so.5...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgconf-2.so.5 > > Reading symbols from /usr/local/lib/libORBit-2.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libORBit-2.so.0 > > Reading symbols from /lib/libm.so.3...(no debugging symbols > > found)...done. Loaded symbols for /lib/libm.so.3 > > Reading symbols from /usr/local/lib/libgmodule-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libgmodule-2.0.so.600 > > Reading symbols from /usr/local/lib/libgthread-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libgthread-2.0.so.600 > > Reading symbols from /usr/X11R6/lib/libgnome-menu.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnome-menu.so.0 > > Reading symbols from /usr/local/lib/libglib-2.0.so.600...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libglib-2.0.so.600 > > Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libiconv.so.3 > > Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libpopt.so.0 > > Reading symbols from /usr/lib/libthr.so.1...(no debugging symbols > > found)...done. > > [New Thread 0x853400 (LWP 100100)] > > [New Thread 0x57c000 (LWP 100124)] > > Loaded symbols for /usr/lib/libthr.so.1 > > Reading symbols from /lib/libc.so.6...(no debugging symbols > > found)...done. Loaded symbols for /lib/libc.so.6 > > Reading symbols from /usr/local/lib/libintl.so.6...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libintl.so.6 > > Reading symbols from /usr/X11R6/lib/libgnome-keyring.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/X11R6/lib/libgnome-keyring.so.0 > > Reading symbols from /usr/local/lib/libjpeg.so.9...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libjpeg.so.9 > > Reading symbols from /usr/local/lib/libesd.so.2...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libesd.so.2 > > Reading symbols from /usr/local/lib/libaudiofile.so.0...(no > > debugging symbols found)...done. > > Loaded symbols for /usr/local/lib/libaudiofile.so.0 > > Reading symbols from /usr/lib/libssl.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/lib/libssl.so.3 > > Reading symbos from /lib/libcrypto.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /lib/libcrypto.so.3 > > Reading symbols from > > /usr/local/lib/libORBitCosNaming-2.so.0...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 > > Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libexpat.so.5 > > Reading symbols from > > /usr/X11R6/lib/X11/locale/lib/common/xlocale.so.2...(no debugging > > symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/X11/locale/lib/common/xlocale.so.2 Reading symbols > > from > > /usr/X11R6/lib/X11/locale/lib/common/xlibi18n.so.2...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/X11/locale/lib/common/xlibi18n.so.2 Reading > > symbols from > > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libthinice.so...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libthinice.so Reading > > symbols from > > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libredmond95.so...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/gtk-2.0/2.4.0/engines/libredmond95.so Reading > > symbols from > > /usr/X11R6/lib/pango/1.4.0/modules/pango-basic-fc.so...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/pango/1.4.0/modules/pango-basic-fc.so Reading > > symbols from > > /usr/X11R6/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so > > Reading symbols from /usr/local/lib/libpng.so.5...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/local/lib/libpng.so.5 > > Reading symbols from > > /usr/local/lib/bonobo/monikers/libmoniker_std_2.so...(no > > debugging symbols found)...done. > > Loaded symbols for > > /usr/local/lib/bonobo/monikers/libmoniker_std_2.so Reading > > symbols from > > /usr/X11R6/lib/gnome-vfs-2.0/modules/libfile.so...(no debugging > > symbols found)...done. > > Loaded symbols for > > /usr/X11R6/lib/gnome-vfs-2.0/modules/libfile.so Reading symbols > > from /usr/local/lib/libfam.so.0...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libfam.so.0 > > Reading symbols from /usr/lib/libstdc++.so.4...(no debugging > > symbols found)...done. > > Loaded symbols for /usr/lib/libstdc++.so.4 > > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > > found)...done. > > Loaded symbols for /libexec/ld-elf.so.1 > > [Switching to Thread 0x853400 (LWP 100100)] > > 0x00000008040a935c in poll () from /lib/libc.so.6 > > (gdb) info threads > > 2 Thread 0x57c000 (LWP 100124) 0x00000008040a9a1c in connect > > () from /lib/libc.so.6 > > * 1 Thread 0x853400 (LWP 100100) 0x00000008040a935c in poll () > > from /lib/libc.so.6 > > (gdb) thread 2 > > [Switching to thread 2 (Thread 0x57c000 (LWP 100124))]#0 > > 0x00000008040a9a1c in connect () from /lib/libc.so.6 > > (gdb) bt > > #0 0x00000008040a9a1c in connect () from /lib/libc.so.6 > > #1 0x0000000803f4a823 in connect () from /usr/lib/libthr.so.1 > > #2 0x000000080458d7b3 in esd_connect_unix () from > > /usr/local/lib/libesd.so.2 > > #3 0x000000080458dbeb in esd_open_sound () from > > /usr/local/lib/libesd.so.2 #4 0x0000000800f13c82 in > > gnome_config_set_sync_handler () from > > /usr/X11R6/lib/libgnome-2.so.1000 > > #5 0x0000000800f14139 in gnome_sound_connection_get () > > from /usr/X11R6/lib/libgnome-2.so.1000 > > #6 0x0000000800f1459e in gnome_triggers_add_trigger () > > from /usr/X11R6/lib/libgnome-2.so.1000 > > #7 0x0000000800f146e8 in gnome_triggers_vdo () > > from /usr/X11R6/lib/libgnome-2.so.1000 > > #8 0x0000000800f149ba in gnome_triggers_do () > > from /usr/X11R6/lib/libgnome-2.so.1000 > > #9 0x0000000800814c81 in gnome_client_request_save () > > from /usr/X11R6/lib/libgnomeui-2.so.1000 > > #10 0x0000000000441622 in panel_init_stock_icons_and_items () > > #11 0x00000008032b2fcf in g_closure_invoke () > > from /usr/local/lib/libgobject-2.0.so.600 > > #12 0x00000008032c714e in g_signal_has_handler_pending () > > from /usr/local/lib/libgobject-2.0.so.600 > > #13 0x00000008032c82cb in g_signal_emit_valist () > > from /usr/local/lib/libgobject-2.0.so.600 > > #14 0x00000008032c86a3 in _signal_emit () > > ---Type to continue, or q to quit--- > > from /usr/local/lib/libgobject-2.0.so.600 > > #15 0x000000080196e852 in gtk_widget_activate () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #16 0x000000080189fbf0 in gtk_menu_shell_activate_item () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #17 0x000000080189fefb in gtk_menu_shell_activate_item () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #18 0x0000000801891576 in gtk_marshal_VOID__UINT_STRING () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #19 0x00000008032b2fcf in g_closure_invoke () > > from /usr/local/lib/libgobject-2.0.so.600 > > #20 0x00000008032c6d39 in g_signal_has_handler_pending () > > from /usr/local/lib/libgobject-2.0.so.600 > > #21 0x00000008032c8001 in g_signal_emit_valist () > > from /usr/local/lib/libgobject-2.0.so.600 > > #22 0x00000008032c86a3 in g_signal_emit () > > from /usr/local/lib/libgobject-2.0.so.600 > > #23 0x000000080196e9b0 in gtk_widget_activate () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #24 0x000000080188f961 in gtk_propagate_event () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #25 0x000000080188fc9c in gtk_main_do_event () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #26 0x0000000801dda5a0 in gdk_event_get_graphics_expose () > > ---Type to continue, or q to quit--- > > from /usr/X11R6/lib/libgdk-x11-2.0.so.600 > > #27 0x0000000803ae75bd in g_main_context_dispatch () > > from /usr/local/lib/libglib-2.0.so.600 > > #28 0x0000000803ae923c in g_main_context_acquire () > > from /usr/local/lib/libglib-2.0.so.600 > > #29 0x0000000803ae95c9 in g_main_loop_run () > > from /usr/local/lib/libglib-2.0.so.600 > > #30 0x000000080188f181 in gtk_main () > > from /usr/X11R6/lib/libgtk-x11-2.0.so.600 > > #31 0x000000000042275e in main () > > (gdb) info thread > > * 2 Thread 0x57c000 (LWP 100124) 0x00000008040a9a1c in connect > > () from /lib/libc.so.6 > > 1 Thread 0x853400 (LWP 100100) 0x00000008040a935c in poll () > > from /lib/libc.so.6 > > (gdb) therad rread 1 > > [Switching to thread 1 (Thread 0x853400 (LWP 100100))]#0 > > 0x00000008040a935c in poll () from /lib/libc.so.6 > > (gdb) bt > > #0 0x00000008040a935c in poll () from /lib/libc.so.6 > > #1 0x0000000803f4adb5 in poll () from /usr/lib/libthr.so.1 > > #2 0x0000000803ae91ce in g_main_context_acquire () > > from /usr/local/lib/libglib-2.0.so.600 > > #3 0x0000000803ae95c9 in g_main_loop_run () > > from /usr/local/lib/libglib-2.0.so.600 > > #4 0x00000008035648f0 in link_io_thread_fn () > > from /usr/local/lib/libORBit-2.so.0 > > #5 0x0000000803b01842 in g_static_private_free () > > from /usr/local/lib/libglib-2.0.so.600 > > #6 0x0000000803f5392c in pthread_create () from > > /usr/lib/libthr.so.1 #7 0x000000080409afe4 in makecontext () > > from /lib/libc.so.6 #8 0x0000000000000000 in ?? () > > #9 0x0000000000853400 in ?? () > > #10 0x0000000000000000 in ?? () > > #11 0x0000000000000000 in ?? () > > #12 0x0000000000000000 in ?? () > > #13 0x0000000000000000 in ?? () > > #14 0x0000000000000000 in ?? () > > Error accessing memory address 0x7fffffbff000: Bad address. > > (gdb) detach > > Detaching from program: /usr/X11R6/bin/gnome-panel, process 738 > > (gdb) quit > > davidxu@alona:/home/davidxu> exit > > > > exit > > > > Script done on Sun Apr 17 07:59:25 2005 From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 00:51:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B286F16A548 for ; Wed, 20 Apr 2005 00:51:43 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A3EB43D2F for ; Wed, 20 Apr 2005 00:51:43 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3K0phOc003681 for ; Tue, 19 Apr 2005 17:51:43 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Apr 2005 17:51:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2005 17:51:42 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C83A02E@bcs-mail3.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cannot log on as root after upgrade Thread-Index: AcVFQxfPZxpxREyFTDSQGji5oA3ydA== From: "Li, Qing" To: X-OriginalArrivalTime: 20 Apr 2005 00:51:32.0407 (UTC) FILETIME=[18611C70:01C54543] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 00:51:45 -0000 I performed a cvs sync today and buildworld. After the system reboot I cannot log on as root, the error message that is shown on console is "login: pam_acct_mgmt(): authentication error". I can still log on as a normal user. What do I need to do to fix this? Did I screw something up during mergemaster ? -- Qing From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 01:04:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CC916A4CE for ; Wed, 20 Apr 2005 01:04:43 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B56C43D1F for ; Wed, 20 Apr 2005 01:04:42 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j3K14QBv041350; Tue, 19 Apr 2005 20:04:27 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4265AA6D.5070406@centtech.com> Date: Tue, 19 Apr 2005 20:03:41 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Li, Qing" References: <48D44BB27BDE3840BDF18E59CB169A5C83A02E@bcs-mail3.internal.cacheflow.com> In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C83A02E@bcs-mail3.internal.cacheflow.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 01:04:43 -0000 Li, Qing wrote: > I performed a cvs sync today and buildworld. After the system > reboot > I cannot log on as root, the error message that is shown on > console > is "login: pam_acct_mgmt(): authentication error". > I can still log on as a normal user. > > What do I need to do to fix this? Did I screw something up during > mergemaster ? Sounds like it - can you boot into single user mode and check out your passwd file? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 01:29:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 308FC16A4CE for ; Wed, 20 Apr 2005 01:29:09 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078CB43D2D for ; Wed, 20 Apr 2005 01:29:09 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3K1T2P3004854; Tue, 19 Apr 2005 18:29:02 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Apr 2005 18:28:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 19 Apr 2005 18:28:59 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C592378@bcs-mail3.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cannot log on as root after upgrade Thread-Index: AcVFRO9EXyBYzGPETcSF1KLume9GUgAA0RLL From: "Li, Qing" To: "Eric Anderson" X-OriginalArrivalTime: 20 Apr 2005 01:28:51.0972 (UTC) FILETIME=[4F439C40:01C54548] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 cc: freebsd-current@freebsd.org Subject: RE: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 01:29:09 -0000 WWVzLCBJIGJvb3RlZCBpbnRvIHNpbmdsZSB1c2VyIGFuZCBjaGFuZ2VkIHBhc3N3b3JkLg0KSG93 ZXZlciwgcnVuIGludG8gdGhlIHNhbWUgcHJvYmxlbSBhZnRlciB0aGUgcmVib290Lg0KIA0KLS0g UWluZw0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogRXJpYyBBbmRl cnNvbiBbbWFpbHRvOmFuZGVyc29uQGNlbnR0ZWNoLmNvbV0gDQoJU2VudDogVHVlIDQvMTkvMjAw NSA2OjAzIFBNIA0KCVRvOiBMaSwgUWluZyANCglDYzogZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qu b3JnIA0KCVN1YmplY3Q6IFJlOiBjYW5ub3QgbG9nIG9uIGFzIHJvb3QgYWZ0ZXIgdXBncmFkZQ0K CQ0KCQ0KDQoJTGksIFFpbmcgd3JvdGU6DQoJPiAgICAgICBJIHBlcmZvcm1lZCBhIGN2cyBzeW5j IHRvZGF5IGFuZCBidWlsZHdvcmxkLiBBZnRlciB0aGUgc3lzdGVtDQoJPiByZWJvb3QNCgk+ICAg ICAgIEkgY2Fubm90IGxvZyBvbiBhcyByb290LCB0aGUgZXJyb3IgbWVzc2FnZSB0aGF0IGlzIHNo b3duIG9uDQoJPiBjb25zb2xlDQoJPiAgICAgICBpcyAibG9naW46IHBhbV9hY2N0X21nbXQoKTog YXV0aGVudGljYXRpb24gZXJyb3IiLg0KCT4gICAgICAgSSBjYW4gc3RpbGwgbG9nIG9uIGFzIGEg bm9ybWFsIHVzZXIuDQoJPg0KCT4gICAgICAgV2hhdCBkbyBJIG5lZWQgdG8gZG8gdG8gZml4IHRo aXM/IERpZCBJIHNjcmV3IHNvbWV0aGluZyB1cCBkdXJpbmcNCgk+ICAgICAgIG1lcmdlbWFzdGVy ID8NCgkNCglTb3VuZHMgbGlrZSBpdCAtIGNhbiB5b3UgYm9vdCBpbnRvIHNpbmdsZSB1c2VyIG1v ZGUgYW5kIGNoZWNrIG91dCB5b3VyIHBhc3N3ZCBmaWxlPw0KCQ0KCQ0KCUVyaWMNCgkNCgkNCgkN CgktLQ0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCUVyaWMgQW5kZXJzb24gICAgICAgIFNyLiBTeXN0ZW1z IEFkbWluaXN0cmF0b3IgICAgICAgIENlbnRhdXIgVGVjaG5vbG9neQ0KCUEgbG9zdCBvdW5jZSBv ZiBnb2xkIG1heSBiZSBmb3VuZCwgYSBsb3N0IG1vbWVudCBvZiB0aW1lIG5ldmVyLg0KCS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KCQ0KDQo= From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 01:34:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5498E16A4CE for ; Wed, 20 Apr 2005 01:34:17 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86B2F43D53 for ; Wed, 20 Apr 2005 01:34:16 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3K1YEDV073731; Tue, 19 Apr 2005 20:34:15 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4265B169.5010901@centtech.com> Date: Tue, 19 Apr 2005 20:33:29 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Li, Qing" References: <48D44BB27BDE3840BDF18E59CB169A5C592378@bcs-mail3.internal.cacheflow.com> In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C592378@bcs-mail3.internal.cacheflow.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/842/Tue Apr 19 16:39:01 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 01:34:17 -0000 Li, Qing wrote: > Yes, I booted into single user and changed password. > However, run into the same problem after the reboot. When was the last time you cvs'ed and built world? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:10:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C967416A4CE for ; Wed, 20 Apr 2005 02:10:44 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9894D43D31 for ; Wed, 20 Apr 2005 02:10:44 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3K2AcdU006107; Tue, 19 Apr 2005 19:10:38 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Apr 2005 19:10:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 19 Apr 2005 19:10:37 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C592379@bcs-mail3.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cannot log on as root after upgrade Thread-Index: AcVFSREzPza+ZoHNQp2q6AtpWBK4UwABPnBF From: "Li, Qing" To: "Eric Anderson" X-OriginalArrivalTime: 20 Apr 2005 02:10:27.0643 (UTC) FILETIME=[1ECCC8B0:01C5454E] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 cc: freebsd-current@freebsd.org Subject: RE: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:10:44 -0000 SSBjdnMnZCBhYm91dCA3IGhvdXJzIGFnbyBhbmQgYnVpbGQgd29ybGQgdG9vayBhIHdoaWxlIC4u Lg0KIA0KTXkgcHJldmlvdXMgc3lzdGVtIHdhcyBhbHNvIDYuMC1DVVJSRU5UIHRoYXQgd2FzDQpj dnMnZCBhYm91dCBhIG1vbnRoIGFnby4NCiANCi0tIFFpbmcNCiANCg0KCS0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIA0KCUZyb206IEVyaWMgQW5kZXJzb24gW21haWx0bzphbmRlcnNvbkBjZW50 dGVjaC5jb21dIA0KCVNlbnQ6IFR1ZSA0LzE5LzIwMDUgNjozMyBQTSANCglUbzogTGksIFFpbmcg DQoJQ2M6IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyANCglTdWJqZWN0OiBSZTogY2Fubm90 IGxvZyBvbiBhcyByb290IGFmdGVyIHVwZ3JhZGUNCgkNCgkNCg0KCUxpLCBRaW5nIHdyb3RlOg0K CT4gWWVzLCBJIGJvb3RlZCBpbnRvIHNpbmdsZSB1c2VyIGFuZCBjaGFuZ2VkIHBhc3N3b3JkLg0K CT4gSG93ZXZlciwgcnVuIGludG8gdGhlIHNhbWUgcHJvYmxlbSBhZnRlciB0aGUgcmVib290Lg0K CQ0KCVdoZW4gd2FzIHRoZSBsYXN0IHRpbWUgeW91IGN2cydlZCBhbmQgYnVpbHQgd29ybGQ/DQoJ DQoJRXJpYw0KCQ0KCQ0KCQ0KCS0tDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJRXJpYyBBbmRlcnNvbiAg ICAgICAgU3IuIFN5c3RlbXMgQWRtaW5pc3RyYXRvciAgICAgICAgQ2VudGF1ciBUZWNobm9sb2d5 DQoJQSBsb3N0IG91bmNlIG9mIGdvbGQgbWF5IGJlIGZvdW5kLCBhIGxvc3QgbW9tZW50IG9mIHRp bWUgbmV2ZXIuDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJDQoNCg== From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:48:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B9E716A4CE; Wed, 20 Apr 2005 02:48:26 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE84643D1F; Wed, 20 Apr 2005 02:48:25 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from stealth.local (jn@c-24-2-72-123.hsd1.ut.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j3K2mNgj083529; Tue, 19 Apr 2005 19:48:23 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Tue, 19 Apr 2005 20:48:04 -0600 User-Agent: KMail/1.8 References: <20050418185148.GA15795@odin.ac.hmc.edu> In-Reply-To: <20050418185148.GA15795@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504192048.05348.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:48:26 -0000 On Monday 18 April 2005 12:51 pm, Brooks Davis wrote: > I've just committed support for IPv6 to IPFW. Various versions of the > pack have been in use for some time, but it's a large change so be > careful. I got a kernel build error on yesterday's sources. I'm running -CURRENT and using a custom kernel that does not include INET6 but does include IPFIREWALL, IPDIVERT, and DUMMYNET. The error message (not copy-pasted) is below: linking kernel ip_dummynet.o: In function 'transmit_event': : undefined reference to 'ip6_output' ip_dummynet.o: In function 'transmit_event': : undefined reference to 'ip6_input' ip_fw2.o: In function 'search_ip6_addr_net': : undefined reference to 'in6_clearscope' *** Error code 1 JN From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:48:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B9E716A4CE; Wed, 20 Apr 2005 02:48:26 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE84643D1F; Wed, 20 Apr 2005 02:48:25 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from stealth.local (jn@c-24-2-72-123.hsd1.ut.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j3K2mNgj083529; Tue, 19 Apr 2005 19:48:23 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Tue, 19 Apr 2005 20:48:04 -0600 User-Agent: KMail/1.8 References: <20050418185148.GA15795@odin.ac.hmc.edu> In-Reply-To: <20050418185148.GA15795@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504192048.05348.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:48:26 -0000 On Monday 18 April 2005 12:51 pm, Brooks Davis wrote: > I've just committed support for IPv6 to IPFW. Various versions of the > pack have been in use for some time, but it's a large change so be > careful. I got a kernel build error on yesterday's sources. I'm running -CURRENT and using a custom kernel that does not include INET6 but does include IPFIREWALL, IPDIVERT, and DUMMYNET. The error message (not copy-pasted) is below: linking kernel ip_dummynet.o: In function 'transmit_event': : undefined reference to 'ip6_output' ip_dummynet.o: In function 'transmit_event': : undefined reference to 'ip6_input' ip_fw2.o: In function 'search_ip6_addr_net': : undefined reference to 'in6_clearscope' *** Error code 1 JN From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:51:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5464416A4CE; Wed, 20 Apr 2005 02:51:48 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C6543D3F; Wed, 20 Apr 2005 02:51:47 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K2phv0050768; Wed, 20 Apr 2005 12:21:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 20 Apr 2005 12:21:38 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2579633.g02zoSvJJl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201221.39355.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Bill Paul cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:51:48 -0000 --nextPart2579633.g02zoSvJJl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 08:26, Bill Paul wrote: > The objcopy(1) trick basically produces an ELF file that has the > Windows .SYS file encapsulated with in it. Two symbols are created > to denote the start end end of the image so that it can be loaded later. > The windrv_stub.o module linked with the Windows image provides a > small FreeBSD modevent handler that hooks the driver into Project > Evil and eventually causes a bus-reprobe. This means that all you > have to do is kldload this one module into the kernel, and presto! > a new ndisX networking interface appears. What about if you want to use >1 NDIS driver? How will it avoid symbol name= =20 collisions? > The end result is that installing a Windows driver should be as simple > as: > > - run the script > - give it your foo.inf and foo.sys files when it asks you > - it spits out a foo_sys.ko module and you kldload it > - the end Sounds much nicer :) > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > iconv, but the script automates the use of all these tooks and explains > to the user what's going on while it's working. It's certainly simpler than the current state of afairs and unless the kern= el=20 NDIS grows the ability to directly read .sys & .inf files from your disk=20 (which would be very cool :) it's about a simple as it's going to get.. > - What should the script be called? wintobsd.sh sounds kind of lame. encappe win2elf pe2elf =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 --nextPart2579633.g02zoSvJJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZcO75ZPcIHs/zowRAmtUAKCqJGRLE2dZzqv4PA1xnRzX9iOZGwCeKfHP 7UXPSSZDop5mc/rd1faJmm4= =xt0l -----END PGP SIGNATURE----- --nextPart2579633.g02zoSvJJl-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:51:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5464416A4CE; Wed, 20 Apr 2005 02:51:48 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C6543D3F; Wed, 20 Apr 2005 02:51:47 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K2phv0050768; Wed, 20 Apr 2005 12:21:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 20 Apr 2005 12:21:38 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2579633.g02zoSvJJl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201221.39355.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Bill Paul cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:51:48 -0000 --nextPart2579633.g02zoSvJJl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 08:26, Bill Paul wrote: > The objcopy(1) trick basically produces an ELF file that has the > Windows .SYS file encapsulated with in it. Two symbols are created > to denote the start end end of the image so that it can be loaded later. > The windrv_stub.o module linked with the Windows image provides a > small FreeBSD modevent handler that hooks the driver into Project > Evil and eventually causes a bus-reprobe. This means that all you > have to do is kldload this one module into the kernel, and presto! > a new ndisX networking interface appears. What about if you want to use >1 NDIS driver? How will it avoid symbol name= =20 collisions? > The end result is that installing a Windows driver should be as simple > as: > > - run the script > - give it your foo.inf and foo.sys files when it asks you > - it spits out a foo_sys.ko module and you kldload it > - the end Sounds much nicer :) > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > iconv, but the script automates the use of all these tooks and explains > to the user what's going on while it's working. It's certainly simpler than the current state of afairs and unless the kern= el=20 NDIS grows the ability to directly read .sys & .inf files from your disk=20 (which would be very cool :) it's about a simple as it's going to get.. > - What should the script be called? wintobsd.sh sounds kind of lame. encappe win2elf pe2elf =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 --nextPart2579633.g02zoSvJJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZcO75ZPcIHs/zowRAmtUAKCqJGRLE2dZzqv4PA1xnRzX9iOZGwCeKfHP 7UXPSSZDop5mc/rd1faJmm4= =xt0l -----END PGP SIGNATURE----- --nextPart2579633.g02zoSvJJl-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 02:52:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D55B16A4CE; Wed, 20 Apr 2005 02:52:25 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB0F443D1F; Wed, 20 Apr 2005 02:52:24 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j3K2qLYS020912; Tue, 19 Apr 2005 22:52:23 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Tue, 19 Apr 2005 22:52:21 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Jung-uk Kim In-Reply-To: <200504192011.57723.jkim@niksun.com> Message-ID: <20050419223603.M76920@sasami.jurai.net> References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A7BE.3070606@freebsd.org><200504192011.57723.jkim@niksun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Tue, 19 Apr 2005 22:52:24 -0400 (EDT) cc: freebsd-current@FreeBSD.ORG cc: David Xu cc: freebsd-ports@FreeBSD.ORG Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 02:52:25 -0000 On Tue, 19 Apr 2005, Jung-uk Kim wrote: > Reverting the following commit fixed the problem: > > http://docs.freebsd.org/cgi/mid.cgi?200504130001.j3D01kuD081602 I see what the problem is. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 03:05:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B71D16A4CE; Wed, 20 Apr 2005 03:05:05 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD2CE43D1D; Wed, 20 Apr 2005 03:05:04 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j3K351A7021804; Tue, 19 Apr 2005 23:05:03 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Tue, 19 Apr 2005 23:05:01 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Jung-uk Kim In-Reply-To: <200504192011.57723.jkim@niksun.com> Message-ID: <20050419225811.A76920@sasami.jurai.net> References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A7BE.3070606@freebsd.org><200504192011.57723.jkim@niksun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Tue, 19 Apr 2005 23:05:04 -0400 (EDT) cc: freebsd-current@FreeBSD.ORG cc: David Xu cc: freebsd-ports@FreeBSD.ORG Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 03:05:05 -0000 >>> #1 0x0000000803f4a823 in connect () from /usr/lib/libthr.so.1 >>> #2 0x000000080458d7b3 in esd_connect_unix () from >>> /usr/local/lib/libesd.so.2 >>> #3 0x000000080458dbeb in esd_open_sound () from >>> /usr/local/lib/libesd.so.2 #4 0x0000000800f13c82 in The problem starts in libesd. esd.c: int open_listen_socket(const char *hostname, int port ) ... socket_listen=socket(AF_UNIX, SOCK_STREAM, 0); ... { int n = 1; setsockopt(socket_listen, SOL_SOCKET, SO_REUSEADDR, &n, sizeof(n)); /* if it fails, so what */ } And continues through some header files... sys/socket.h: #define SO_REUSEADDR 0x0004 /* allow local address reuse */ sys/un.h: #define LOCAL_CONNWAIT 0x004 /* connects block until accepted */ And finally ends up in sys/kern/uipc_usrreq.c:uipc_ctloutput() where we fail to check the 'level' argument to getsockopt(). Fix committed etc. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:04:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0019816A4CE; Wed, 20 Apr 2005 04:04:08 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B08343D48; Wed, 20 Apr 2005 04:04:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3K448Hh002662; Tue, 19 Apr 2005 21:04:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3K4482L002661; Tue, 19 Apr 2005 21:04:08 -0700 Date: Tue, 19 Apr 2005 21:04:08 -0700 From: Brooks Davis To: John Nielsen Message-ID: <20050420040407.GA24712@odin.ac.hmc.edu> References: <20050418185148.GA15795@odin.ac.hmc.edu> <200504192048.05348.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <200504192048.05348.lists@jnielsen.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:04:09 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 08:48:04PM -0600, John Nielsen wrote: > On Monday 18 April 2005 12:51 pm, Brooks Davis wrote: > > I've just committed support for IPv6 to IPFW. Various versions of the > > pack have been in use for some time, but it's a large change so be > > careful. >=20 > I got a kernel build error on yesterday's sources. I'm running -CURRENT = and=20 > using a custom kernel that does not include INET6 but does include=20 > IPFIREWALL, IPDIVERT, and DUMMYNET. The error message (not copy-pasted) = is=20 > below: >=20 > linking kernel > ip_dummynet.o: In function 'transmit_event': > : undefined reference to 'ip6_output' > ip_dummynet.o: In function 'transmit_event': > : undefined reference to 'ip6_input' > ip_fw2.o: In function 'search_ip6_addr_net': > : undefined reference to 'in6_clearscope' > *** Error code 1 I believe phk fixed that bug. The changes looked fine to me, but I haven't actually tried to compile them yet. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCZdS3XY6L6fI4GtQRAgTMAKC6MF6kel6dDWxcncERSHwhH5a68wCgnQLV Pdwr5iF6onwbO0iAwdky+5o= =zOUi -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:04:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0019816A4CE; Wed, 20 Apr 2005 04:04:08 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B08343D48; Wed, 20 Apr 2005 04:04:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3K448Hh002662; Tue, 19 Apr 2005 21:04:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3K4482L002661; Tue, 19 Apr 2005 21:04:08 -0700 Date: Tue, 19 Apr 2005 21:04:08 -0700 From: Brooks Davis To: John Nielsen Message-ID: <20050420040407.GA24712@odin.ac.hmc.edu> References: <20050418185148.GA15795@odin.ac.hmc.edu> <200504192048.05348.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <200504192048.05348.lists@jnielsen.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:04:09 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 08:48:04PM -0600, John Nielsen wrote: > On Monday 18 April 2005 12:51 pm, Brooks Davis wrote: > > I've just committed support for IPv6 to IPFW. Various versions of the > > pack have been in use for some time, but it's a large change so be > > careful. >=20 > I got a kernel build error on yesterday's sources. I'm running -CURRENT = and=20 > using a custom kernel that does not include INET6 but does include=20 > IPFIREWALL, IPDIVERT, and DUMMYNET. The error message (not copy-pasted) = is=20 > below: >=20 > linking kernel > ip_dummynet.o: In function 'transmit_event': > : undefined reference to 'ip6_output' > ip_dummynet.o: In function 'transmit_event': > : undefined reference to 'ip6_input' > ip_fw2.o: In function 'search_ip6_addr_net': > : undefined reference to 'in6_clearscope' > *** Error code 1 I believe phk fixed that bug. The changes looked fine to me, but I haven't actually tried to compile them yet. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCZdS3XY6L6fI4GtQRAgTMAKC6MF6kel6dDWxcncERSHwhH5a68wCgnQLV Pdwr5iF6onwbO0iAwdky+5o= =zOUi -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:06:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D80816A4CE for ; Wed, 20 Apr 2005 04:06:01 +0000 (GMT) Received: from area51.capnet.state.tx.us (area51.capnet.state.tx.us [141.198.193.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5254043D1D for ; Wed, 20 Apr 2005 04:06:01 +0000 (GMT) (envelope-from gartrend@area51.capnet.state.tx.us) Received: from area51.capnet.state.tx.us (localhost.capnet.state.tx.us [127.0.0.1])j3K43kbM030359 for ; Tue, 19 Apr 2005 23:03:46 -0500 (CDT) (envelope-from gartrend@area51.capnet.state.tx.us) Received: from localhost (gartrend@localhost)j3K43kD4030356 for ; Tue, 19 Apr 2005 23:03:46 -0500 (CDT) Date: Tue, 19 Apr 2005 23:03:46 -0500 (CDT) From: marek gartrend To: freebsd-current@freebsd.org Message-ID: <20050419224935.G30305@area51.capnet.state.tx.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FreeBSD 5.4 RC3 failure on Gateway ALR 7200R. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:06:01 -0000 I tried to load 5.4-RC3 (please redirect me to the correct list if this isn't the one) on a Gateway ALR 7200R, dual processor 400MHz Pentium II. The normal boot from the CD would not boot, stopping at the agp0: line. I booted to safe mode and installed from there. When I boot it stops at: agp0: at device 1.0 on pci0 in safe bood mode, the next line is: pcib1: at device 1.0 on pci0 If I boot with extra logging, it ends with: agp0: at device 1.0 on pci0 agp0: Lazy allocation of 0x4000000 bytes rid 0x10 type 3 at 0 agp0: allocating GATT for aperture size of 64M [nothing more] I tried setting ACPI off (cause it was the only thing I know how to do) with: hint.acpi.0.disabled="1" in loader.conf (I also tried putting it in device.hints) but that made no difference. Is this machine a no-go? garth From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:13:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5250D16A4CE; Wed, 20 Apr 2005 04:13:47 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C0343D45; Wed, 20 Apr 2005 04:13:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 5300C1F47B6; Tue, 19 Apr 2005 21:13:46 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j3K4Daej014553; Tue, 19 Apr 2005 21:13:45 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4265D6E9.2050600@elischer.org> Date: Tue, 19 Apr 2005 21:13:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Daniel O'Connor" References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:13:47 -0000 Daniel O'Connor wrote: > > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > encappe winbind? > win2elf > pe2elf > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:13:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5250D16A4CE; Wed, 20 Apr 2005 04:13:47 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C0343D45; Wed, 20 Apr 2005 04:13:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 5300C1F47B6; Tue, 19 Apr 2005 21:13:46 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j3K4Daej014553; Tue, 19 Apr 2005 21:13:45 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4265D6E9.2050600@elischer.org> Date: Tue, 19 Apr 2005 21:13:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Daniel O'Connor" References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:13:47 -0000 Daniel O'Connor wrote: > > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > encappe winbind? > win2elf > pe2elf > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:52:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2550616A4CE; Wed, 20 Apr 2005 04:52:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74DD43D41; Wed, 20 Apr 2005 04:52:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3K4s86u085661; Tue, 19 Apr 2005 22:54:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4265DF30.8010001@samsco.org> Date: Tue, 19 Apr 2005 22:48:48 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:52:08 -0000 Daniel O'Connor wrote: > On Wed, 20 Apr 2005 08:26, Bill Paul wrote: > >>The objcopy(1) trick basically produces an ELF file that has the >>Windows .SYS file encapsulated with in it. Two symbols are created >>to denote the start end end of the image so that it can be loaded later. >>The windrv_stub.o module linked with the Windows image provides a >>small FreeBSD modevent handler that hooks the driver into Project >>Evil and eventually causes a bus-reprobe. This means that all you >>have to do is kldload this one module into the kernel, and presto! >>a new ndisX networking interface appears. > > > What about if you want to use >1 NDIS driver? How will it avoid symbol name > collisions? > > >>The end result is that installing a Windows driver should be as simple >>as: >> >>- run the script >>- give it your foo.inf and foo.sys files when it asks you >>- it spits out a foo_sys.ko module and you kldload it >>- the end > > > Sounds much nicer :) > > >>You still end up needing the C compiler, objcopy, ndiscvt and (optionally) >>iconv, but the script automates the use of all these tooks and explains >>to the user what's going on while it's working. > > > It's certainly simpler than the current state of afairs and unless the kernel > NDIS grows the ability to directly read .sys & .inf files from your disk > (which would be very cool :) it's about a simple as it's going to get.. > > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > encappe > win2elf > pe2elf > necronomicon? Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:52:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2550616A4CE; Wed, 20 Apr 2005 04:52:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74DD43D41; Wed, 20 Apr 2005 04:52:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3K4s86u085661; Tue, 19 Apr 2005 22:54:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4265DF30.8010001@samsco.org> Date: Tue, 19 Apr 2005 22:48:48 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:52:08 -0000 Daniel O'Connor wrote: > On Wed, 20 Apr 2005 08:26, Bill Paul wrote: > >>The objcopy(1) trick basically produces an ELF file that has the >>Windows .SYS file encapsulated with in it. Two symbols are created >>to denote the start end end of the image so that it can be loaded later. >>The windrv_stub.o module linked with the Windows image provides a >>small FreeBSD modevent handler that hooks the driver into Project >>Evil and eventually causes a bus-reprobe. This means that all you >>have to do is kldload this one module into the kernel, and presto! >>a new ndisX networking interface appears. > > > What about if you want to use >1 NDIS driver? How will it avoid symbol name > collisions? > > >>The end result is that installing a Windows driver should be as simple >>as: >> >>- run the script >>- give it your foo.inf and foo.sys files when it asks you >>- it spits out a foo_sys.ko module and you kldload it >>- the end > > > Sounds much nicer :) > > >>You still end up needing the C compiler, objcopy, ndiscvt and (optionally) >>iconv, but the script automates the use of all these tooks and explains >>to the user what's going on while it's working. > > > It's certainly simpler than the current state of afairs and unless the kernel > NDIS grows the ability to directly read .sys & .inf files from your disk > (which would be very cool :) it's about a simple as it's going to get.. > > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > encappe > win2elf > pe2elf > necronomicon? Scott From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:54:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D9E16A4CE; Wed, 20 Apr 2005 04:54:54 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CAB43D53; Wed, 20 Apr 2005 04:54:53 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K4si7T053410; Wed, 20 Apr 2005 14:24:45 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Julian Elischer Date: Wed, 20 Apr 2005 14:24:13 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> <4265D6E9.2050600@elischer.org> In-Reply-To: <4265D6E9.2050600@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3386945.56jkdP2qD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201424.35175.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:54:54 -0000 --nextPart3386945.56jkdP2qD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 13:43, Julian Elischer wrote: > Daniel O'Connor wrote: > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > > encappe > > winbind? That could be a bit confusing because Samba's PAM/NSS daemon is called=20 windbindd.. =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 --nextPart3386945.56jkdP2qD2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZeCK5ZPcIHs/zowRAqWuAKCU3X4K09bb+hwGZzqLjM5moJZK0ACgqU+U 7GFU/HGCU2v7BTSTBb2A3l8= =5kjn -----END PGP SIGNATURE----- --nextPart3386945.56jkdP2qD2-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:54:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D9E16A4CE; Wed, 20 Apr 2005 04:54:54 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CAB43D53; Wed, 20 Apr 2005 04:54:53 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K4si7T053410; Wed, 20 Apr 2005 14:24:45 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Julian Elischer Date: Wed, 20 Apr 2005 14:24:13 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <200504201221.39355.doconnor@gsoft.com.au> <4265D6E9.2050600@elischer.org> In-Reply-To: <4265D6E9.2050600@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3386945.56jkdP2qD2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201424.35175.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Bill Paul cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:54:54 -0000 --nextPart3386945.56jkdP2qD2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 13:43, Julian Elischer wrote: > Daniel O'Connor wrote: > >>- What should the script be called? wintobsd.sh sounds kind of lame. > > > > encappe > > winbind? That could be a bit confusing because Samba's PAM/NSS daemon is called=20 windbindd.. =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 --nextPart3386945.56jkdP2qD2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZeCK5ZPcIHs/zowRAqWuAKCU3X4K09bb+hwGZzqLjM5moJZK0ACgqU+U 7GFU/HGCU2v7BTSTBb2A3l8= =5kjn -----END PGP SIGNATURE----- --nextPart3386945.56jkdP2qD2-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 04:56:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64BC716A4CE for ; Wed, 20 Apr 2005 04:56:31 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A23EC43D3F for ; Wed, 20 Apr 2005 04:56:30 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3K4uF9h081670; Wed, 20 Apr 2005 00:56:15 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3K4uB6E081667; Wed, 20 Apr 2005 00:56:15 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Wed, 20 Apr 2005 00:56:11 -0400 (EDT) From: Andre Guibert de Bruet To: "Li, Qing" In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C592379@bcs-mail3.internal.cacheflow.com> Message-ID: <20050420005221.B64858@lexi.siliconlandmark.com> References: <48D44BB27BDE3840BDF18E59CB169A5C592379@bcs-mail3.internal.cacheflow.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.532, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: RE: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 04:56:31 -0000 On Tue, 19 Apr 2005, Li, Qing wrote: > I cvs'd about 7 hours ago and build world took a while ... > > My previous system was also 6.0-CURRENT that was > cvs'd about a month ago. The generic path for recovery is as follows: - Boot up in single user mode. - Manually configure network interface(s). - cvsup again. - "make world" in /usr/src, still in single-user mode. - mergemaster -i - boot into multi-user mode. Give that a whirl... Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:02:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0BAE16A4CE for ; Wed, 20 Apr 2005 05:02:46 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 737A243D31 for ; Wed, 20 Apr 2005 05:02:46 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3K52g4C081772; Wed, 20 Apr 2005 01:02:42 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3K52gxv081769; Wed, 20 Apr 2005 01:02:42 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Wed, 20 Apr 2005 01:02:42 -0400 (EDT) From: Andre Guibert de Bruet To: Steve Ames In-Reply-To: <20050419165227.GA86651@energistic.com> Message-ID: <20050420005744.Y64858@lexi.siliconlandmark.com> References: <200504191530.j3JFUvWD030545@energistic.com> <42652533.8060106@centtech.com><20050419160623.GA2922@energistic.com> <20050419165227.GA86651@energistic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.533, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:02:46 -0000 On Tue, 19 Apr 2005, Steve Ames wrote: > Hrm. Almost the same as you. On mine that first comparison is actually > "!= //boot/kernel". Likely because I have "DESTDIR?=/" in /etc/make.conf. > > Hrm. Suddenly all makes sense. I defined DESTDIR so that 'make world' > would continue to work normally (instead of doing buildworld/installworld) > and that probably happened around August '04. > > So I guess if I get rid of DESTDIR and start doing buildworld/installworld > then I get kernel.old functionality again... however this tastes like a > bug to me. Perhaps that comparison should be: > > "!= ${DESTIR}/boot/kernel" ?? This is not a bug. You are looking for the functionality that is offered by HISTORICAL_MAKE_WORLD. Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:12:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3096A16A4CE for ; Wed, 20 Apr 2005 05:12:13 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B268F43D3F for ; Wed, 20 Apr 2005 05:12:12 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id c51so47584rne for ; Tue, 19 Apr 2005 22:12:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f9q/Q/cM30692v7cSOIO9vzFokmqM1lHJfXxaEE377eMvVKCeMR+xbltBvVgZ9LMxuXp8alf7J6FWksePgcqYfeuC4PJSRu6EqS4LrWpJJr397O2w+Iblo6MJc81gpstve45Eed17Ga7qNxqzroYgkp+t8RJmfD9Iob6Nb3qNqs= Received: by 10.38.15.7 with SMTP id 7mr461640rno; Tue, 19 Apr 2005 22:12:12 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Tue, 19 Apr 2005 22:12:11 -0700 (PDT) Message-ID: <84dead720504192212215482f8@mail.gmail.com> Date: Wed, 20 Apr 2005 05:12:11 +0000 From: Joseph Koshy To: Marcel Moolenaar In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050419184115.0BFA37306E@freebsd-current.sentex.ca> cc: ia64@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:12:13 -0000 > FYI: I'm on it, but the tinderbox will continue to fail until=20 > I have something to commit. This should be in a couple of days > at the most. My fault: I didn't do a full 'make universe' run before=20 committing. Am cleaning up now ... --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:22:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 7EFAD16A4CF; Wed, 20 Apr 2005 05:22:40 +0000 (GMT) In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> from "Daniel O'Connor" at "Apr 20, 2005 12:21:38 pm" To: doconnor@gsoft.com.au (Daniel O'Connor) Date: Wed, 20 Apr 2005 05:22:40 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050420052240.7EFAD16A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:22:40 -0000 > On Wed, 20 Apr 2005 08:26, Bill Paul wrote: > > The objcopy(1) trick basically produces an ELF file that has the > > Windows .SYS file encapsulated with in it. Two symbols are created > > to denote the start end end of the image so that it can be loaded later. > > The windrv_stub.o module linked with the Windows image provides a > > small FreeBSD modevent handler that hooks the driver into Project > > Evil and eventually causes a bus-reprobe. This means that all you > > have to do is kldload this one module into the kernel, and presto! > > a new ndisX networking interface appears. > > What about if you want to use >1 NDIS driver? How will it avoid symbol name > collisions? Collisions during driver loading are avoided by having windrv_stub.c obtain a unique name for the DRIVER_MODULE() macros and friends. As for network interfaces, they will all end up named ndisX. In my testing, I put an Atheros card and Intel 2200BG card in the same system. If I kldload w22n51_sys.ko first, ndis0 is created which maps to the Intel card, and then loading ar5211_sys.ko creates ndis1, which maps to the Atheros card. If I load the modules in the reverse order, ndis0 becomes the Atheros card and ndis1 becomes the Intel card. During bootstrap, order depends on the PCI bus probe order. Note that a kldload foo_sys.ko will automatically force a load of ndis.ko and if_ndis.ko. I had to rig things such that unloading one of the converted modules forces a detach of all devices associated with that module. Failing to do this would leave a network interface in place that depends on a non-existent .SYS image. I was hoping to find a way to trick the module dependency mechanism into handling this for me, but came up empty. So instead, windrv_unload() hunts down all the device handles for any dependent interfaces and does an explicit device_detach() on them. > > The end result is that installing a Windows driver should be as simple > > as: > > > > - run the script > > - give it your foo.inf and foo.sys files when it asks you > > - it spits out a foo_sys.ko module and you kldload it > > - the end > > Sounds much nicer :) I put a snapshot of the code (relative to -current) at: http://www.freebsd.org/~wpaul/ndis_snap.tar.gz The script and stub file are in the usr.sbin/ndiscvt directory. The script still needs a bit of work, but handles most basic cases. > > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > > iconv, but the script automates the use of all these tooks and explains > > to the user what's going on while it's working. > > It's certainly simpler than the current state of afairs and unless the kernel > NDIS grows the ability to directly read .sys & .inf files from your disk > (which would be very cool :) it's about a simple as it's going to get.. Putting a .INF parser in the kernel would not be cool at all. Kernels are for managing hardware and herding applications, not parsing text files. > > - What should the script be called? wintobsd.sh sounds kind of lame. > > encappe > win2elf > pe2elf Hm... have to think about these. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:25:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7455116A4CE; Wed, 20 Apr 2005 05:25:34 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E411D43D1F; Wed, 20 Apr 2005 05:25:33 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id A501229216A; Wed, 20 Apr 2005 01:23:15 -0400 (EDT) Date: Wed, 20 Apr 2005 01:23:15 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: Bill Paul In-Reply-To: <20050420052240.7EFAD16A4CF@hub.freebsd.org> Message-ID: References: <20050420052240.7EFAD16A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:25:34 -0000 Bill Paul, it's good to see that you're still working on this project. Do let me know if you need any assistance. --sahil On Wed, 20 Apr 2005, Bill Paul wrote: >> On Wed, 20 Apr 2005 08:26, Bill Paul wrote: >>> The objcopy(1) trick basically produces an ELF file that has the >>> Windows .SYS file encapsulated with in it. Two symbols are created >>> to denote the start end end of the image so that it can be loaded later. >>> The windrv_stub.o module linked with the Windows image provides a >>> small FreeBSD modevent handler that hooks the driver into Project >>> Evil and eventually causes a bus-reprobe. This means that all you >>> have to do is kldload this one module into the kernel, and presto! >>> a new ndisX networking interface appears. >> >> What about if you want to use >1 NDIS driver? How will it avoid symbol name >> collisions? > > Collisions during driver loading are avoided by having windrv_stub.c > obtain a unique name for the DRIVER_MODULE() macros and friends. > As for network interfaces, they will all end up named ndisX. In my testing, > I put an Atheros card and Intel 2200BG card in the same system. > If I kldload w22n51_sys.ko first, ndis0 is created which maps to > the Intel card, and then loading ar5211_sys.ko creates ndis1, which > maps to the Atheros card. If I load the modules in the reverse order, > ndis0 becomes the Atheros card and ndis1 becomes the Intel card. > During bootstrap, order depends on the PCI bus probe order. > > Note that a kldload foo_sys.ko will automatically force a load > of ndis.ko and if_ndis.ko. > > I had to rig things such that unloading one of the converted modules > forces a detach of all devices associated with that module. Failing > to do this would leave a network interface in place that depends > on a non-existent .SYS image. I was hoping to find a way to trick > the module dependency mechanism into handling this for me, but > came up empty. So instead, windrv_unload() hunts down all the device > handles for any dependent interfaces and does an explicit > device_detach() on them. > >>> The end result is that installing a Windows driver should be as simple >>> as: >>> >>> - run the script >>> - give it your foo.inf and foo.sys files when it asks you >>> - it spits out a foo_sys.ko module and you kldload it >>> - the end >> >> Sounds much nicer :) > > I put a snapshot of the code (relative to -current) at: > > http://www.freebsd.org/~wpaul/ndis_snap.tar.gz > > The script and stub file are in the usr.sbin/ndiscvt directory. The > script still needs a bit of work, but handles most basic cases. > >>> You still end up needing the C compiler, objcopy, ndiscvt and (optionally) >>> iconv, but the script automates the use of all these tooks and explains >>> to the user what's going on while it's working. >> >> It's certainly simpler than the current state of afairs and unless the kernel >> NDIS grows the ability to directly read .sys & .inf files from your disk >> (which would be very cool :) it's about a simple as it's going to get.. > > Putting a .INF parser in the kernel would not be cool at all. Kernels > are for managing hardware and herding applications, not parsing text > files. > >>> - What should the script be called? wintobsd.sh sounds kind of lame. >> >> encappe >> win2elf >> pe2elf > > Hm... have to think about these. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:44:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1841416A4CE; Wed, 20 Apr 2005 05:44:31 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D558143D1D; Wed, 20 Apr 2005 05:44:30 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1 [69.55.238.237]) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j3K5iUgj082575; Tue, 19 Apr 2005 22:44:30 -0700 (PDT) (envelope-from lists@jnielsen.net) Received: (from www@localhost) by ns1.jnielsen.net (8.12.9p2/8.12.9/Submit) id j3K5iUtd082574; Tue, 19 Apr 2005 23:44:30 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: ns1.jnielsen.net: www set sender to lists@jnielsen.net using -f Received: from c-24-2-72-123.hsd1.ut.comcast.net (c-24-2-72-123.hsd1.ut.comcast.net [24.2.72.123]) by webmail.jnielsen.net (IMP) with HTTP for ; Tue, 19 Apr 2005 23:44:30 -0600 Message-ID: <1113975870.4265ec3e6b93f@webmail.jnielsen.net> Date: Tue, 19 Apr 2005 23:44:30 -0600 From: John Nielsen To: Brooks Davis References: <20050418185148.GA15795@odin.ac.hmc.edu> <200504192048.05348.lists@jnielsen.net> <20050420040407.GA24712@odin.ac.hmc.edu> In-Reply-To: <20050420040407.GA24712@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 / FreeBSD-4.9 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:44:31 -0000 Quoting Brooks Davis : [dummynet breakage w/o INET6] > I believe phk fixed that bug. The changes looked fine to me, but I > haven't actually tried to compile them yet. Yep, today's sources compiled fine. Thanks! JN From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:44:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1841416A4CE; Wed, 20 Apr 2005 05:44:31 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D558143D1D; Wed, 20 Apr 2005 05:44:30 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1 [69.55.238.237]) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j3K5iUgj082575; Tue, 19 Apr 2005 22:44:30 -0700 (PDT) (envelope-from lists@jnielsen.net) Received: (from www@localhost) by ns1.jnielsen.net (8.12.9p2/8.12.9/Submit) id j3K5iUtd082574; Tue, 19 Apr 2005 23:44:30 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: ns1.jnielsen.net: www set sender to lists@jnielsen.net using -f Received: from c-24-2-72-123.hsd1.ut.comcast.net (c-24-2-72-123.hsd1.ut.comcast.net [24.2.72.123]) by webmail.jnielsen.net (IMP) with HTTP for ; Tue, 19 Apr 2005 23:44:30 -0600 Message-ID: <1113975870.4265ec3e6b93f@webmail.jnielsen.net> Date: Tue, 19 Apr 2005 23:44:30 -0600 From: John Nielsen To: Brooks Davis References: <20050418185148.GA15795@odin.ac.hmc.edu> <200504192048.05348.lists@jnielsen.net> <20050420040407.GA24712@odin.ac.hmc.edu> In-Reply-To: <20050420040407.GA24712@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 / FreeBSD-4.9 X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: IPv6 support added to IPFW X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:44:31 -0000 Quoting Brooks Davis : [dummynet breakage w/o INET6] > I believe phk fixed that bug. The changes looked fine to me, but I > haven't actually tried to compile them yet. Yep, today's sources compiled fine. Thanks! JN From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 05:53:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9AD916A4CE for ; Wed, 20 Apr 2005 05:53:18 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A32743D2D for ; Wed, 20 Apr 2005 05:53:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 357881F3CC3 for ; Tue, 19 Apr 2005 22:53:16 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j3K5rFmY090744 for ; Tue, 19 Apr 2005 22:53:15 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4265EE40.5030504@elischer.org> Date: Tue, 19 Apr 2005 22:53:04 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR .. sources a few hours old.. vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 05:53:19 -0000 serial console. not doing any work.. just sitting there after booting.... SMP kernel. 1 chip, 2 HTT thingies. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a lock order reversal 1st 0xc0728440 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/kern/vfs_bio.c:1485 2nd 0xc26e8d6c vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:1992 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c06e23c8,c06e0e88,c06aa8c8) at kdb_backtrace+0x29 witness_checkorder(c26e8d6c,9,c067bfad,7c8) at witness_checkorder+0x550 _mtx_lock_flags(c26e8d6c,0,c067bfad,7c8,c105f6b4) at _mtx_lock_flags+0x5b vdrop(c26e8cf0) at vdrop+0x1d vm_page_remove(c10a2078,c10a2078) at vm_page_remove+0xd4 vm_page_free_toq(c10a2078,c10a2078,40,c10a2078,e35db8dc) at vm_page_free_toq+0x90 vm_page_free(c10a2078,c10a2078) at vm_page_free+0x15 vfs_vmio_release(d633a050) at vfs_vmio_release+0x9b brelse(d633a050,c227fa80,1,c0504fa8,0) at brelse+0x485 ffs_mountfs(c26e8cf0,c26c7000,c2282480,c2699c10,0) at ffs_mountfs+0x555 ffs_mount(c26c7000,c2282480,0,0,c26e9000) at ffs_mount+0x9ad vfs_domount(c2282480,c2699c50,c2699c30,4001,c2699c70) at vfs_domount+0x589 vfs_donmount(c2282480,4001,e35dbc20,c26f27c0,6) at vfs_donmount+0xce kernel_mount(c2699c90,4001,e35dbc88,e35dbcb4,c055c61e) at kernel_mount+0x6d kernel_vmount(4001,c067ba14,c2699ca0,c067ba1b,c0676c4c) at kernel_vmount+0x37 vfs_mountroot_try(c26ec000,c066f1b5,204,c2281de4,c04e6a54) at vfs_mountroot_try+0xd2 vfs_mountroot(c2281de4,c2282480,0,c2282480,e35dbcf8) at vfs_mountroot+0x193 start_init(0,e35dbd38,0,c04e6a54,0) at start_init+0x4b fork_exit(c04e6a54,0,e35dbd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35dbd6c, ebp = 0 --- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 06:06:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05DBE16A4CE for ; Wed, 20 Apr 2005 06:06:57 +0000 (GMT) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [128.186.195.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id C97D543D31 for ; Wed, 20 Apr 2005 06:06:56 +0000 (GMT) (envelope-from neuro@mail.fci.fsu.edu) Received: from mail.fci.fsu.edu (mail.fci.fsu.edu [127.0.0.1]) by mail.fci.fsu.edu (Postfix) with ESMTP id 9D21829216A for ; Wed, 20 Apr 2005 02:04:38 -0400 (EDT) Date: Wed, 20 Apr 2005 02:04:38 -0400 (EDT) From: neuro@mail.fci.fsu.edu To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: kernel programming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 06:06:57 -0000 I was just wondering if there is a mailing list i'm un-informed about that deals with kernel programming. I tried finding documentation via google but have found none. If someone could point me in the right direction, that would be nice. I could hack away from the kernel existing source code. sincerely, sahil r cooner From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 06:08:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52A2B16A4CE for ; Wed, 20 Apr 2005 06:08:41 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F9343D2F for ; Wed, 20 Apr 2005 06:08:41 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id EC91351303; Tue, 19 Apr 2005 23:08:39 -0700 (PDT) Date: Tue, 19 Apr 2005 23:08:39 -0700 From: Kris Kennaway To: Julian Elischer Message-ID: <20050420060839.GA15451@xor.obsecurity.org> References: <4265EE40.5030504@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <4265EE40.5030504@elischer.org> User-Agent: Mutt/1.4.2.1i cc: Current Subject: Re: LOR .. sources a few hours old.. vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 06:08:41 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 10:53:04PM -0700, Julian Elischer wrote: > serial console. not doing any work.. just sitting there after booting.... > SMP kernel. 1 chip, 2 HTT thingies. >=20 >=20 >=20 > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad0s1a > lock order reversal > 1st 0xc0728440 vm page queue mutex (vm page queue mutex) @=20 > /usr/src/sys/kern/vfs_bio.c:1485 > 2nd 0xc26e8d6c vnode interlock (vnode interlock) @=20 > /usr/src/sys/kern/vfs_subr.c:1992 This one has been reported a few times already, but I don't know who is responsible for it (maybe Jeff's VFS work) Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZfHmWry0BWjoQKURApEKAJ9XXD38J5r8tz9n3BmEO6zby/XUlACg+pAg xBx4uLuPUOaVMRBz1xgAZHk= =aoZY -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 06:56:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E8D16A4CE for ; Wed, 20 Apr 2005 06:56:19 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F36843D39 for ; Wed, 20 Apr 2005 06:56:18 +0000 (GMT) (envelope-from free.bsd@gmx.net) Received: (qmail invoked by alias); 20 Apr 2005 06:56:15 -0000 Received: from pD9E7FFC8.dip.t-dialin.net (EHLO [192.168.2.101]) [217.231.255.200] by mail.gmx.net (mp031) with SMTP; 20 Apr 2005 08:56:15 +0200 X-Authenticated: #20105305 Message-ID: <4265FCED.8050604@gmx.net> Date: Wed, 20 Apr 2005 14:55:41 +0800 From: FreeBSD Daemon User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: neuro@mail.fci.fsu.edu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 cc: freebsd-current@freebsd.org Subject: Re: kernel programming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 06:56:19 -0000 neuro@mail.fci.fsu.edu wrote: > I was just wondering if there is a mailing list i'm un-informed about > that deals with kernel programming. I tried finding documentation via > google but have found none. > > If someone could point me in the right direction, that would be nice. > I could hack away from the kernel existing source code. > > sincerely, > sahil r cooner > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > Well, first and foremost the source code, I'd say. For how to get it cf. to the handbook chapter 19: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.html And then there is a whole bunch of information of kernelprogramming in the documentation: http://www.freebsd.org/docs.html If you want to dive further into "The Design and Implementation of the FreeBSD Operating System" you probably want to look at http://www.aw-bc.com/catalog/academic/product/0,1144,0201702452,00.html Zheyu From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 07:04:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5D9C16A4CE; Wed, 20 Apr 2005 07:04:32 +0000 (GMT) Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C4143D31; Wed, 20 Apr 2005 07:04:31 +0000 (GMT) (envelope-from gb@isis.u-strasbg.fr) Received: from localhost (localhost.u-strasbg.fr [127.0.0.1]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 1DD4223EF7; Wed, 20 Apr 2005 09:04:30 +0200 (CEST) Received: from chimie.u-strasbg.fr ([127.0.0.1]) by localhost (chimie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08917-01; Wed, 20 Apr 2005 09:04:30 +0200 (CEST) Received: from 6nq.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77]) by chimie.u-strasbg.fr (Postfix) with ESMTP id D94C523EEF; Wed, 20 Apr 2005 09:04:29 +0200 (CEST) Received: by 6nq.u-strasbg.fr (Postfix, from userid 1001) id 741A6640F; Wed, 20 Apr 2005 09:03:07 +0200 (CEST) Date: Wed, 20 Apr 2005 09:03:07 +0200 From: Guy Brand To: freebsd-acpi@freebsd.org Message-ID: <20050420070307.GA928@chimie.u-strasbg.fr> References: <20050417205230.GC837@chimie.u-strasbg.fr> <4263E9BF.4050501@root.org> <20050418192235.GA867@chimie.u-strasbg.fr> <42640C2B.20100@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <42640C2B.20100@root.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by ClamAV at chimie.u-strasbg.fr cc: freebsd-current@freebsd.org Subject: Re: hw.acpi.battery.life always at 100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 07:04:32 -0000 On 18 avril at 12:36, Nate Lawson wrote: > I'm adding -current to the CC since a change elsewhere in the kernel may > have triggered this. Is anyone aware why it appears interrupts are now > disabled for a while just after launching init? The change appeared in > 5-STABLE between March 17 and April 17. > > Guy, can you try disabling usb? Also, can you cvsup to dates between > March 17 and April 17 to try to narrow down the exact date this started > occurring? Hi all, Nate, I followed your instructions. First of all disabling USB didn't change anything. I then suped RELENG_5 to several dates in between March 17 and April 17 and found that the problem appeared after Mar-31-05:00 and before Mar-31-11:00. cvsup between these two timestamps shows two changes: Edit src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml Add delta 1.761.2.38 2005.03.31.06.28.58 hrs Edit src/sys/dev/acpica/acpivar.h Add delta 1.79.2.7 2005.03.31.06.03.59 njl and diffing acpivar.h reveals: @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/dev/acpica/acpivar.h,v 1.79.2.6 2005/03/02 09:18:41 obrien Exp $ + * $FreeBSD: src/sys/dev/acpica/acpivar.h,v 1.79.2.7 2005/03/31 06:03:59 njl Exp $ */ #ifndef _ACPIVAR_H_ @@ -406,7 +406,7 @@ ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj); #ifndef ACPI_MAX_THREADS -#define ACPI_MAX_THREADS 3 +#define ACPI_MAX_THREADS 1 #endif /* ACPI task kernel thread initialization. */ I suped back to 5-STABLE and changed ACPI_MAX_THREADS accordingly and the problem has now disappeared: # sysctl hw.acpi.battery hw.acpi.battery.life: 87 hw.acpi.battery.time: 167 hw.acpi.battery.state: 1 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 # uname -a FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #7: Wed Apr 20 00:49:58 CEST 2005 root@6nq.u-strasbg.fr:/usr/obj/usr/src/sys/GENERIC i386 BTW -CURRENT has the same problem (MFC from 1.91) and the same change fixes it. gb From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 08:43:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B71616A4CE; Wed, 20 Apr 2005 08:43:16 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D86043D2F; Wed, 20 Apr 2005 08:43:15 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd19.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1DOAni-0005Db-03; Wed, 20 Apr 2005 10:43:14 +0200 Received: from Andro-Beta.Leidinger.net (VT5KqeZdgebl3-n2wx8bRa6UziNhi8Wrg2eadiflgVLSlws7ajEjEe@[84.128.205.214]) by fwd19.sul.t-online.de with esmtp id 1DOAnc-0KtiS00; Wed, 20 Apr 2005 10:43:08 +0200 Received: from localhost (localhost [127.0.0.1])j3K8h9Bj017661; Wed, 20 Apr 2005 10:43:09 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 20 Apr 2005 10:43:09 +0200 Message-ID: <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 20 Apr 2005 10:43:09 +0200 From: Alexander Leidinger To: Bill Paul References: <20050419225640.7B92816A4CF@hub.freebsd.org> In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: VT5KqeZdgebl3-n2wx8bRa6UziNhi8Wrg2eadiflgVLSlws7ajEjEe@t-dialin.net X-TOI-MSGID: 1dabf7a6-c87e-4255-8d79-566cc464d6bf cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 08:43:16 -0000 Bill Paul wrote: > Anyway. The things I have yet to determine are: > > - Where should windrv_stub.c ultimately be installed? I'm thinking it > should go in /usr/share/misc. > > - What should the script be called? wintobsd.sh sounds kind of lame. > > Any suggestions or comments on my mad scheme would be welcome. Can this be extended to also cover other binary blobs like firmware images, so we just have one way to do it? I'm thinking about e.g. the just recently committed WLAN drivers or about cxm (WinTV PVR250 driver in multimedia/pvr250). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Isn't it nice that people who prefer Los Angeles to San Francisco live there? -- Herb Caen From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 08:45:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 242F716A4CE; Wed, 20 Apr 2005 08:45:40 +0000 (GMT) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C3AE43D46; Wed, 20 Apr 2005 08:45:39 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.50 (FreeBSD)) id 1DOAq0-0000NU-Nn; Wed, 20 Apr 2005 12:45:36 +0400 From: Vladimir Grebenschikov To: Bill Paul In-Reply-To: <20050420052240.7EFAD16A4CF@hub.freebsd.org> References: <20050420052240.7EFAD16A4CF@hub.freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 20 Apr 2005 12:45:36 +0400 Message-Id: <1113986736.1162.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 08:45:40 -0000 =F7 =D3=D2, 20/04/2005 =D7 05:22 +0000, Bill Paul =D0=C9=DB=C5=D4: > > > You still end up needing the C compiler, objcopy, ndiscvt and (option= ally) > > > iconv, but the script automates the use of all these tooks and explai= ns > > > to the user what's going on while it's working. > >=20 > > It's certainly simpler than the current state of afairs and unless the = kernel=20 > > NDIS grows the ability to directly read .sys & .inf files from your dis= k=20 > > (which would be very cool :) it's about a simple as it's going to get.. >=20 > Putting a .INF parser in the kernel would not be cool at all. Kernels > are for managing hardware and herding applications, not parsing text > files. Probably any parsing should be done in user-space utility, which will load .SYS file into kernel. # ndisload w22n51.inf w22n51.sys It should parse .inf, load if_ndis/ndis if required and then supply them binary data to use (via sysctl interface or like) This can be alternative way (instead of compiling special .ko) It is not so useful for mass-deploying, but more useful for day-to-day life. What do you think ?=20 > -Bill --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 09:07:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E189916A4CE; Wed, 20 Apr 2005 09:07:57 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D521F43D1F; Wed, 20 Apr 2005 09:07:56 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K97jea057161; Wed, 20 Apr 2005 18:37:45 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 20 Apr 2005 18:37:32 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> In-Reply-To: <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1774876.WsGjo0eTpa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201837.40830.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Alexander Leidinger cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 09:07:58 -0000 --nextPart1774876.WsGjo0eTpa Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 18:13, Alexander Leidinger wrote: > > Any suggestions or comments on my mad scheme would be welcome. > > Can this be extended to also cover other binary blobs like firmware image= s, > so we just have one way to do it? I'm thinking about e.g. the just recent= ly > committed WLAN drivers or about cxm (WinTV PVR250 driver in > multimedia/pvr250). I would suggest the driver loads the firmware from disk since you don't nee= d=20 to boot from your TV tuner card :) =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 --nextPart1774876.WsGjo0eTpa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZhvc5ZPcIHs/zowRAjsxAJ9EGzrqV/d6gIQ3yITBrFavXjq5uwCcDqMH vn8P1yWxsj1/UuJFpOdHydM= =WMxE -----END PGP SIGNATURE----- --nextPart1774876.WsGjo0eTpa-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 09:07:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E189916A4CE; Wed, 20 Apr 2005 09:07:57 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D521F43D1F; Wed, 20 Apr 2005 09:07:56 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3K97jea057161; Wed, 20 Apr 2005 18:37:45 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 20 Apr 2005 18:37:32 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> In-Reply-To: <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1774876.WsGjo0eTpa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504201837.40830.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Alexander Leidinger cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 09:07:58 -0000 --nextPart1774876.WsGjo0eTpa Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 18:13, Alexander Leidinger wrote: > > Any suggestions or comments on my mad scheme would be welcome. > > Can this be extended to also cover other binary blobs like firmware image= s, > so we just have one way to do it? I'm thinking about e.g. the just recent= ly > committed WLAN drivers or about cxm (WinTV PVR250 driver in > multimedia/pvr250). I would suggest the driver loads the firmware from disk since you don't nee= d=20 to boot from your TV tuner card :) =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 --nextPart1774876.WsGjo0eTpa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZhvc5ZPcIHs/zowRAjsxAJ9EGzrqV/d6gIQ3yITBrFavXjq5uwCcDqMH vn8P1yWxsj1/UuJFpOdHydM= =WMxE -----END PGP SIGNATURE----- --nextPart1774876.WsGjo0eTpa-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 09:21:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB39B16A4CE; Wed, 20 Apr 2005 09:21:31 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2C4F43D45; Wed, 20 Apr 2005 09:21:31 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j3K9LThW000750; Wed, 20 Apr 2005 02:21:29 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j3K9LTOB000749; Wed, 20 Apr 2005 02:21:29 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Apr 2005 02:21:28 -0700 From: Luigi Rizzo To: "Daniel O'Connor" Message-ID: <20050420022128.B421@xorpc.icir.org> References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <200504201837.40830.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200504201837.40830.doconnor@gsoft.com.au>; from doconnor@gsoft.com.au on Wed, Apr 20, 2005 at 06:37:32PM +0930 cc: Alexander Leidinger cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 09:21:32 -0000 On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: ... > I would suggest the driver loads the firmware from disk since you don't need > to boot from your TV tuner card :) why not ? it's a kind of a network device, after all... :) cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 09:21:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB39B16A4CE; Wed, 20 Apr 2005 09:21:31 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2C4F43D45; Wed, 20 Apr 2005 09:21:31 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j3K9LThW000750; Wed, 20 Apr 2005 02:21:29 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j3K9LTOB000749; Wed, 20 Apr 2005 02:21:29 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Apr 2005 02:21:28 -0700 From: Luigi Rizzo To: "Daniel O'Connor" Message-ID: <20050420022128.B421@xorpc.icir.org> References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <200504201837.40830.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200504201837.40830.doconnor@gsoft.com.au>; from doconnor@gsoft.com.au on Wed, Apr 20, 2005 at 06:37:32PM +0930 cc: Alexander Leidinger cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 09:21:32 -0000 On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: ... > I would suggest the driver loads the firmware from disk since you don't need > to boot from your TV tuner card :) why not ? it's a kind of a network device, after all... :) cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 09:33:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB6B16A4CE; Wed, 20 Apr 2005 09:33:52 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C5043D2F; Wed, 20 Apr 2005 09:33:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j3K9XpBf000916; Wed, 20 Apr 2005 02:33:51 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j3K9Xpet000915; Wed, 20 Apr 2005 02:33:51 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Apr 2005 02:33:51 -0700 From: Luigi Rizzo To: Bill Paul Message-ID: <20050420023351.C421@xorpc.icir.org> References: <200504201221.39355.doconnor@gsoft.com.au> <20050420052240.7EFAD16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050420052240.7EFAD16A4CF@hub.freebsd.org>; from wpaul@freebsd.org on Wed, Apr 20, 2005 at 05:22:40AM +0000 cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 09:33:52 -0000 On Wed, Apr 20, 2005 at 05:22:40AM +0000, Bill Paul wrote: ... > > What about if you want to use >1 NDIS driver? How will it avoid symbol name > > collisions? i don't understand the issue of name collisions though. Assuming that things work in the same way as dlopen() (which seems to be the case according to the documentation) the symbols in the module that we kldload are not globally visible, but keyed by fileid and only accessible through kldsym(). So the collisions are only in the filenames that we kldload, not in the individual symbols. Then it suffices to rename the patched files... cheers luigi > Collisions during driver loading are avoided by having windrv_stub.c > obtain a unique name for the DRIVER_MODULE() macros and friends. > As for network interfaces, they will all end up named ndisX. In my testing, > I put an Atheros card and Intel 2200BG card in the same system. > If I kldload w22n51_sys.ko first, ndis0 is created which maps to > the Intel card, and then loading ar5211_sys.ko creates ndis1, which > maps to the Atheros card. If I load the modules in the reverse order, > ndis0 becomes the Atheros card and ndis1 becomes the Intel card. > During bootstrap, order depends on the PCI bus probe order. > > Note that a kldload foo_sys.ko will automatically force a load > of ndis.ko and if_ndis.ko. > > I had to rig things such that unloading one of the converted modules > forces a detach of all devices associated with that module. Failing > to do this would leave a network interface in place that depends > on a non-existent .SYS image. I was hoping to find a way to trick > the module dependency mechanism into handling this for me, but > came up empty. So instead, windrv_unload() hunts down all the device > handles for any dependent interfaces and does an explicit > device_detach() on them. > > > > The end result is that installing a Windows driver should be as simple > > > as: > > > > > > - run the script > > > - give it your foo.inf and foo.sys files when it asks you > > > - it spits out a foo_sys.ko module and you kldload it > > > - the end > > > > Sounds much nicer :) > > I put a snapshot of the code (relative to -current) at: > > http://www.freebsd.org/~wpaul/ndis_snap.tar.gz > > The script and stub file are in the usr.sbin/ndiscvt directory. The > script still needs a bit of work, but handles most basic cases. > > > > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > > > iconv, but the script automates the use of all these tooks and explains > > > to the user what's going on while it's working. > > > > It's certainly simpler than the current state of afairs and unless the kernel > > NDIS grows the ability to directly read .sys & .inf files from your disk > > (which would be very cool :) it's about a simple as it's going to get.. > > Putting a .INF parser in the kernel would not be cool at all. Kernels > are for managing hardware and herding applications, not parsing text > files. > > > > - What should the script be called? wintobsd.sh sounds kind of lame. > > > > encappe > > win2elf > > pe2elf > > Hm... have to think about these. > > -Bill > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems > ============================================================================= > you're just BEGGING to face the moose > ============================================================================= > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 10:44:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CD8C16A4CE; Wed, 20 Apr 2005 10:44:23 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 203B543D2D; Wed, 20 Apr 2005 10:44:23 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DOCgw-000ECa-KL; Wed, 20 Apr 2005 10:44:22 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DOCgq-0000I1-Hy; Wed, 20 Apr 2005 00:44:16 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16998.12927.778881.441108@roam.psg.com> Date: Wed, 20 Apr 2005 00:44:15 -1000 To: "Matthew N. Dodd" References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A7BE.3070606@freebsd.org> <200504192011.57723.jkim@niksun.com> <20050419225811.A76920@sasami.jurai.net> cc: freebsd-current@freebsd.org Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 10:44:23 -0000 > Fix committed etc. fix solves my problem starting X/gnome on a thinkpad t41. mahalo! kevin, does this also get your systems flying again? randy From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:03:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3027C16A4CE for ; Wed, 20 Apr 2005 11:03:41 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E3AB43D49 for ; Wed, 20 Apr 2005 11:03:40 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so105020rne for ; Wed, 20 Apr 2005 04:03:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FKrcT9CP1EvE/ZIiCo70VZ24ZxcCQFWIXHyaCoxFDqG+s3febdvuZtCKVUsG7r9kZlXF2rr2h9ygMjX8COEkKdFSkl43D+1qS1a4JxfsKOdkMIhZ54MbwGHuyc3od8ndqW0ZksGSEOK/zb+7JB6Pd4MzaYMpb4Kk733aQ0eDVxI= Received: by 10.38.65.13 with SMTP id n13mr738610rna; Wed, 20 Apr 2005 04:03:39 -0700 (PDT) Received: by 10.38.209.22 with HTTP; Wed, 20 Apr 2005 04:03:39 -0700 (PDT) Message-ID: <84dead7205042004035deab766@mail.gmail.com> Date: Wed, 20 Apr 2005 11:03:39 +0000 From: Joseph Koshy To: FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: LOR vm_map_insert > vm_map_find X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:03:41 -0000 >From current of the 20th: # kldload hwpmc lock order reversal 1st 0xffffff001eff00f0 system map (system map) @ /home/fcpi/src/sys/vm/vm_= map.c :1100 2nd 0xffffff0013e048c0 vm object (standard object) @ /home/fcpi/src/sys/vm/vm_map.c:897 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x5f1 _mtx_lock_flags() at _mtx_lock_flags+0x4a vm_map_insert() at vm_map_insert+0x115 vm_map_find() at vm_map_find+0x9d link_elf_load_file() at link_elf_load_file+0x811 linker_load_module() at linker_load_module+0x50e kldload() at kldload+0xc3 syscall() at syscall+0x4ab Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (304, FreeBSD ELF64, kldload), rip =3D 0x8006791ac, rsp =3D 0x7= fffffffeb 38, rbp =3D 0x7fffffffebb0 --- hwpmc: TSC(1) K8(4) --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:12:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F81B16A4FE; Wed, 20 Apr 2005 11:12:10 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 046D143D31; Wed, 20 Apr 2005 11:12:10 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3KBC7Za061183; Wed, 20 Apr 2005 11:12:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4266390F.1090702@freebsd.org> Date: Wed, 20 Apr 2005 19:12:15 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew N. Dodd" References: <20050414164406.2bfbeff5@ale.varnet.bsd> <4261A7BE.3070606@freebsd.org><200504192011.57723.jkim@niksun.com> <20050419225811.A76920@sasami.jurai.net> In-Reply-To: <20050419225811.A76920@sasami.jurai.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-ports@freebsd.org cc: Jung-uk Kim Subject: Re: gnome can not shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:12:10 -0000 Matthew N. Dodd wrote: >>>> #1 0x0000000803f4a823 in connect () from /usr/lib/libthr.so.1 >>>> #2 0x000000080458d7b3 in esd_connect_unix () from >>>> /usr/local/lib/libesd.so.2 >>>> #3 0x000000080458dbeb in esd_open_sound () from >>>> /usr/local/lib/libesd.so.2 #4 0x0000000800f13c82 in >>> > > The problem starts in libesd. > > esd.c: > > int open_listen_socket(const char *hostname, int port ) > ... > socket_listen=socket(AF_UNIX, SOCK_STREAM, 0); > ... > { > int n = 1; > setsockopt(socket_listen, SOL_SOCKET, SO_REUSEADDR, &n, sizeof(n)); > /* if it fails, so what */ > } > > And continues through some header files... > > sys/socket.h: > > #define SO_REUSEADDR 0x0004 /* allow local address reuse */ > > sys/un.h: > > #define LOCAL_CONNWAIT 0x004 /* connects block until accepted */ > > And finally ends up in sys/kern/uipc_usrreq.c:uipc_ctloutput() where > we fail to check the 'level' argument to getsockopt(). > > Fix committed etc. > it works fine again, thanks! David Xu From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:18:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65A1516A4CE; Wed, 20 Apr 2005 11:18:00 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5E5643D31; Wed, 20 Apr 2005 11:17:59 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd20.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1DODDR-0007jD-01; Wed, 20 Apr 2005 13:17:57 +0200 Received: from Andro-Beta.Leidinger.net (ZqwqtsZlQeiSJ4qLqKVwR1oJuujxPO8FP5h7NsloFWmOC2dLl+bQkD@[84.128.205.214]) by fwd20.sul.t-online.de with esmtp id 1DODDE-1H2SZs0; Wed, 20 Apr 2005 13:17:44 +0200 Received: from localhost (localhost [127.0.0.1])j3KBHisi040212; Wed, 20 Apr 2005 13:17:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 20 Apr 2005 13:17:44 +0200 Message-ID: <20050420131744.t092cv40dck804ww@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 20 Apr 2005 13:17:44 +0200 From: Alexander Leidinger To: Luigi Rizzo References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <200504201837.40830.doconnor@gsoft.com.au> <20050420022128.B421@xorpc.icir.org> In-Reply-To: <20050420022128.B421@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: ZqwqtsZlQeiSJ4qLqKVwR1oJuujxPO8FP5h7NsloFWmOC2dLl+bQkD@t-dialin.net X-TOI-MSGID: 88061a6f-2493-4fa0-857b-e096b46da1a4 cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:18:00 -0000 Luigi Rizzo wrote: > On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: > ... >> I would suggest the driver loads the firmware from disk since you don't need >> to boot from your TV tuner card :) AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the tree needs a firmware blob, ath needs a blob (but the license seems to be ok, so we can have it in the tree), the newly added WLAN drivers need a binary blob and some other pieces need a blob too. Having a general way of adding the blob would be better than reinventing the wheel. > why not ? it's a kind of a network device, after all... :) ---snip--- PXE booting from cxa0: Connecting to Channel 5... done. Booting CSI at 0x0.... ---snip--- ;-) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 BOFH excuse #185: system consumed all the paper for paging From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:18:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65A1516A4CE; Wed, 20 Apr 2005 11:18:00 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5E5643D31; Wed, 20 Apr 2005 11:17:59 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd20.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1DODDR-0007jD-01; Wed, 20 Apr 2005 13:17:57 +0200 Received: from Andro-Beta.Leidinger.net (ZqwqtsZlQeiSJ4qLqKVwR1oJuujxPO8FP5h7NsloFWmOC2dLl+bQkD@[84.128.205.214]) by fwd20.sul.t-online.de with esmtp id 1DODDE-1H2SZs0; Wed, 20 Apr 2005 13:17:44 +0200 Received: from localhost (localhost [127.0.0.1])j3KBHisi040212; Wed, 20 Apr 2005 13:17:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 20 Apr 2005 13:17:44 +0200 Message-ID: <20050420131744.t092cv40dck804ww@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 20 Apr 2005 13:17:44 +0200 From: Alexander Leidinger To: Luigi Rizzo References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <200504201837.40830.doconnor@gsoft.com.au> <20050420022128.B421@xorpc.icir.org> In-Reply-To: <20050420022128.B421@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: ZqwqtsZlQeiSJ4qLqKVwR1oJuujxPO8FP5h7NsloFWmOC2dLl+bQkD@t-dialin.net X-TOI-MSGID: 88061a6f-2493-4fa0-857b-e096b46da1a4 cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:18:00 -0000 Luigi Rizzo wrote: > On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: > ... >> I would suggest the driver loads the firmware from disk since you don't need >> to boot from your TV tuner card :) AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the tree needs a firmware blob, ath needs a blob (but the license seems to be ok, so we can have it in the tree), the newly added WLAN drivers need a binary blob and some other pieces need a blob too. Having a general way of adding the blob would be better than reinventing the wheel. > why not ? it's a kind of a network device, after all... :) ---snip--- PXE booting from cxa0: Connecting to Channel 5... done. Booting CSI at 0x0.... ---snip--- ;-) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 BOFH excuse #185: system consumed all the paper for paging From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:30:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD60116A4CE; Wed, 20 Apr 2005 11:30:38 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE3BC43D1F; Wed, 20 Apr 2005 11:30:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3KBUV4I059490; Wed, 20 Apr 2005 21:00:31 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Alexander Leidinger Date: Wed, 20 Apr 2005 21:00:29 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420022128.B421@xorpc.icir.org> <20050420131744.t092cv40dck804ww@netchild.homeip.net> In-Reply-To: <20050420131744.t092cv40dck804ww@netchild.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1455262.jxsyn17kSc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504202100.30427.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Luigi Rizzo cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:30:39 -0000 --nextPart1455262.jxsyn17kSc Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 20:47, Alexander Leidinger wrote: > Luigi Rizzo wrote: > > On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: > > ... > > > >> I would suggest the driver loads the firmware from disk since you don't > >> need to boot from your TV tuner card :) > > AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the > tree needs a firmware blob, ath needs a blob (but the license seems to be > ok, so we can have it in the tree), the newly added WLAN drivers need a > binary blob and some other pieces need a blob too. Having a general way of > adding the blob would be better than reinventing the wheel. There is how ndis does it at the moment - it could be genericized but it is= n't=20 really that complex at the moment anyway. See NdisOpenFile() and friends. > ---snip--- > PXE booting from cxa0: > Connecting to Channel 5... done. > Booting CSI at 0x0.... > ---snip--- > > ;-) =46reeBSD TV! :) =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 --nextPart1455262.jxsyn17kSc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZj1W5ZPcIHs/zowRArsgAJ90s/gpvpNLDfETHte6U4j3a4QdrACeOtu1 380umrHatYmpgh0INv3Sgqo= =AlNA -----END PGP SIGNATURE----- --nextPart1455262.jxsyn17kSc-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:30:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD60116A4CE; Wed, 20 Apr 2005 11:30:38 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE3BC43D1F; Wed, 20 Apr 2005 11:30:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3KBUV4I059490; Wed, 20 Apr 2005 21:00:31 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Alexander Leidinger Date: Wed, 20 Apr 2005 21:00:29 +0930 User-Agent: KMail/1.8 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420022128.B421@xorpc.icir.org> <20050420131744.t092cv40dck804ww@netchild.homeip.net> In-Reply-To: <20050420131744.t092cv40dck804ww@netchild.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1455262.jxsyn17kSc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504202100.30427.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Luigi Rizzo cc: freebsd-current@freebsd.org cc: current@freebsd.org cc: Bill Paul Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:30:39 -0000 --nextPart1455262.jxsyn17kSc Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 20:47, Alexander Leidinger wrote: > Luigi Rizzo wrote: > > On Wed, Apr 20, 2005 at 06:37:32PM +0930, Daniel O'Connor wrote: > > ... > > > >> I would suggest the driver loads the firmware from disk since you don't > >> need to boot from your TV tuner card :) > > AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the > tree needs a firmware blob, ath needs a blob (but the license seems to be > ok, so we can have it in the tree), the newly added WLAN drivers need a > binary blob and some other pieces need a blob too. Having a general way of > adding the blob would be better than reinventing the wheel. There is how ndis does it at the moment - it could be genericized but it is= n't=20 really that complex at the moment anyway. See NdisOpenFile() and friends. > ---snip--- > PXE booting from cxa0: > Connecting to Channel 5... done. > Booting CSI at 0x0.... > ---snip--- > > ;-) =46reeBSD TV! :) =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 --nextPart1455262.jxsyn17kSc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCZj1W5ZPcIHs/zowRArsgAJ90s/gpvpNLDfETHte6U4j3a4QdrACeOtu1 380umrHatYmpgh0INv3Sgqo= =AlNA -----END PGP SIGNATURE----- --nextPart1455262.jxsyn17kSc-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:37:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E2316A4E4 for ; Wed, 20 Apr 2005 11:37:20 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4D1C43D55 for ; Wed, 20 Apr 2005 11:37:18 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IF800M0LTMSKC@nemesis.sorbs.net> for freebsd-current@freebsd.org; Wed, 20 Apr 2005 21:37:41 +1000 (EST) Date: Wed, 20 Apr 2005 21:36:01 +1000 From: Matthew Sullivan In-reply-to: <20050420084413.GA27304@walton.maths.tcd.ie> To: freebsd-current@freebsd.org Message-id: <42663EA1.3020409@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms040403020704030400060305; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <20050420084413.GA27304@walton.maths.tcd.ie> Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:37:20 -0000 This is a cryptographically signed message in MIME format. --------------ms040403020704030400060305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm going to post this back to the list as Marko was also helping me get to the bottom of it... David Malone wrote: >On Tue, Apr 19, 2005 at 07:29:18AM +1000, Matthew Sullivan wrote: > > >>Any reason why FreeBSD 5.2.1+ and 5.3-p9 set DF on all packets? >> >> > >It is usual to do this to do path MTU discovery with TCP. I don't >know what the situation with the packets that the VPN sends is. > > > >>example with dominator [203.15.51.36] MTU at 1500, vpn server is at >>203.15.51.36 (all interfaces are MTU 1500 except gif0 which is 1280), >>other end of the VPN has interfaces at MTU 1500 which serices the >>10.200.254.0 network (wireless).... >> >>23:36:23.577880 203.15.51.36.24 > 10.200.254.98.33118: . 2315:3763(1448) >>ack 2537 win 33304 (DF) [tos 0x10] >>23:36:23.578406 203.15.51.61 > 203.15.51.36: icmp: 10.200.254.98 >>unreachable - need to frag (DF) >> >> > >It looks like 203.15.51.61 is asking the vpn server to fragment >some packet. I guess that the packet is a encrypted version of the >TCP packet above? I guess that means that either the vpn server >needs to not set the DF bit, or it needs to translate the ICMP >message into something that it can return to the TCP sender. How >to do that probably depends on how you configure the vpn stuff. The >gif man page says that the DF bit should not be set on the packets >that it generates. > > IP addresses involved are: 203.15.51.58 is the webserver (desperado.sorbs.net) 203.15.51.36 is the Old DB server (dominator.sorbs.net) 203.15.51.61 is the VPN terminator (stealth.sorbs.net) 10.200.254.2 is the other end of the VPN (oblivion.isux.com) 10.200.254.98 is my laptop running Slackware Linux, for the dump below I used wget to do a simple GET / FreeBSD oblivion.isux.com 5.3-RELEASE-p8 FreeBSD 5.3-RELEASE-p8 #4: Sun Apr 17 09:55:22 EST 2005 root@oblivion.isux.com:/usr/obj/usr/src/sys/OBLIVION i386 FreeBSD stealth.sorbs.net 5.3-RELEASE-p8 FreeBSD 5.3-RELEASE-p8 #1: Fri Apr 15 15:31:30 EST 2005 root@stealth.sorbs.net:/usr/obj/usr/src/sys/STEALTH i386 FreeBSD desperado.sorbs.net 5.3-RELEASE-p9 FreeBSD 5.3-RELEASE-p9 #3: Fri Apr 15 15:29:29 EST 2005 root@desperado.sorbs.net:/usr/obj/usr/src/sys/DESPERADO amd64 Network is like this (view with fixed font): 10.200.254.98 ^ | wireless net | | 10.200.254.2 192.168.1.2 -----> wired LAN ----- 138.130.dynamic | | ^ 192.168.1.0/24 default | | | \|/ VPN _______|_____|___ | INTERNET | _____________|___ | | /|\ VPN | | 203.101.254.30 <----------- ^ | | VPN | | 203.101.254.254 /|\ 203.15.51.33 | ^ VPN | | default | route VPN Server | 203.101.254.252 | 203.15.51.61 | | ^ -----203.15.51.32/27------------- | | | | | | | 203.15.51.58 203.15.51.36 | | | | | | | -->Route for 10.200.254.0/24----------- and 192.168.1.0/24 I hope that makes sense ;-) Basically the current default route is the old firewall, it is being replaced by the server that is also the VPN server. The VPN terminator (stealth.sorbs.net) is going to be a firewall, however it isn't a firewall yet, therefor the current rules are a simple: pass in from any to any pass out from any to any (ipf enabled, ipfw not compiled in, pf not enabled) Follows is a tcpdump from the VPN terminator: root@stealth:~# tcpdump -i dc0 -n host 203.15.51.58 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on dc0, link-type EN10MB (Ethernet), capture size 96 bytes 21:29:41.026070 arp who-has 203.15.51.58 tell 203.15.51.36 21:29:46.454576 IP 10.200.254.98.33080 > 203.15.51.58.80: SWE 2722075077:2722075077(0) win 5840 21:29:46.454705 IP 203.15.51.58.80 > 10.200.254.98.33080: S 1200777202:1200777202(0) ack 2722075078 win 65535 21:29:46.495554 IP 10.200.254.98.33080 > 203.15.51.58.80: . ack 1 win 5840 21:29:50.721228 IP 10.200.254.98.33080 > 203.15.51.58.80: P 1:17(16) ack 1 win 5840 21:29:50.820112 IP 203.15.51.58.80 > 10.200.254.98.33080: . ack 17 win 33304 21:29:50.863489 IP 10.200.254.98.33080 > 203.15.51.58.80: P 17:21(4) ack 1 win 5840 21:29:50.865526 IP 203.15.51.58.80 > 10.200.254.98.33080: . 1:1449(1448) ack 21 win 33304 21:29:50.865538 IP 203.15.51.58.80 > 10.200.254.98.33080: P 1449:1880(431) ack 21 win 33304 21:29:50.865547 IP 203.15.51.58.80 > 10.200.254.98.33080: F 1880:1880(0) ack 21 win 33304 21:29:50.866097 IP 203.15.51.61 > 203.15.51.58: icmp 36: 10.200.254.98 unreachable - need to frag 21:29:50.929844 IP 10.200.254.98.33080 > 203.15.51.58.80: . ack 1 win 5840 21:29:50.935786 IP 10.200.254.98.33080 > 203.15.51.58.80: . ack 1 win 5840 21:29:57.175022 IP 203.15.51.58.80 > 10.200.254.98.33080: . 1:1449(1448) ack 21 win 33304 21:29:57.175148 IP 203.15.51.61 > 203.15.51.58: icmp 36: 10.200.254.98 unreachable - need to frag 21:30:09.595314 IP 203.15.51.58.80 > 10.200.254.98.33080: . 1:1449(1448) ack 21 win 33304 21:30:09.595498 IP 203.15.51.61 > 203.15.51.58: icmp 36: 10.200.254.98 unreachable - need to frag 21:30:17.561779 IP 203.15.51.58.80 > 10.200.254.98.33072: . 4283830444:4283831892(1448) ack 2167167726 win 33304 21:30:17.561907 IP 203.15.51.61 > 203.15.51.58: icmp 36: 10.200.254.98 unreachable - need to frag 21:30:24.545302 IP 10.200.254.98.33080 > 203.15.51.58.80: P 21:23(2) ack 1 win 5840 21:30:24.545430 IP 203.15.51.58.80 > 10.200.254.98.33080: R 1200777203:1200777203(0) win 0 21:30:37.307121 IP 203.15.51.58.80 > 10.200.254.98.33073: . 3057749166:3057750614(1448) ack 2221689087 win 33304 21:30:37.307248 IP 203.15.51.61 > 203.15.51.58: icmp 36: 10.200.254.98 unreachable - need to frag ^C 25 packets captured 201 packets received by filter 0 packets dropped by kernel If you need it the interfaces on stealth are configured as follows: fxp0: flags=8843 mtu 1500 options=8 inet 203.101.254.252 netmask 0xffffff00 broadcast 203.101.254.255 inet6 fe80::290:27ff:fec2:4977%fxp0 prefixlen 64 scopeid 0x1 ether 00:90:27:c2:49:77 media: Ethernet autoselect (100baseTX ) status: active dc0: flags=108843 mtu 1500 options=8 inet 203.15.51.61 netmask 0xffffffe0 broadcast 203.15.51.63 inet6 fe80::2a0:cff:fec0:cc23%dc0 prefixlen 64 scopeid 0x2 ether 00:a0:0c:c0:cc:23 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 gif0: flags=8051 mtu 1280 tunnel inet 203.101.254.252 --> 138.130.223.244 inet 203.15.51.61 --> 192.168.1.2 netmask 0xffffff00 inet6 fe80::290:27ff:fec2:4977%gif0 prefixlen 64 scopeid 0x5 IPv4 Routing table: Destination Gateway Flags Refs Use Netif Expire default 203.101.254.30 UGS 7 486813 fxp0 10.200.254/24 192.168.1.2 UGS 0 1239 gif0 127.0.0.1 127.0.0.1 UH 0 97 lo0 192.168.1 192.168.1.2 UGS 0 12666 gif0 192.168.1.2 203.15.51.61 UH 2 138 gif0 203.15.51.32/27 link#2 UC 0 0 dc0 203.15.51.33 00:00:e8:3d:c7:f2 UHLW 0 10887 dc0 1191 203.15.51.35 08:00:20:b2:58:e6 UHLW 0 6 dc0 802 203.15.51.36 00:0f:20:30:cd:f0 UHLW 0 14290 dc0 1064 203.15.51.38 02:00:06:e3:44:9a UHLW 0 48 dc0 690 203.15.51.41 02:00:06:e3:44:9a UHLW 0 48 dc0 154 203.15.51.42 02:00:06:e3:44:9a UHLW 0 12 dc0 692 203.15.51.51 08:00:20:b2:58:e6 UHLW 0 0 dc0 776 203.15.51.58 00:09:5b:09:de:2a UHLW 0 32 dc0 872 203.15.51.62 08:00:20:b2:58:e6 UHLW 0 216 dc0 137 203.101.254 link#1 UC 0 0 fxp0 203.101.254.30 00:d0:05:15:0c:0a UHLW 1 0 fxp0 1198 Sorry if it's too much info, if there is anything missing you need, just mail... Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040403020704030400060305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMDExMzYwMVowIwYJKoZIhvcNAQkEMRYEFLYbYUKr41faDSLk QYIBqq5KIeRFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQHTN5T2dkP0H+C78so3XroWaTH5tJmb4viO+PZU/PltdwMoUtGvrZgAY0ooMkNiezUOP iOHAKQajVz6ziKGV994AAAAAAAA= --------------ms040403020704030400060305-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:41:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD82B16A4CE for ; Wed, 20 Apr 2005 11:41:33 +0000 (GMT) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id D4FFB43D45 for ; Wed, 20 Apr 2005 11:41:31 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 32906 invoked by uid 0); 20 Apr 2005 08:41:31 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 Clear:RC:1(200.210.42.5):. Processed in 0.348487 secs); 20 Apr 2005 11:41:31 -0000 Received: from unknown (HELO ?10.69.69.69?) (200.210.42.5) by capeta.freebsdbrasil.com.br with SMTP; 20 Apr 2005 08:41:31 -0300 Message-ID: <42663FE8.7070906@freebsdbrasil.com.br> Date: Wed, 20 Apr 2005 08:41:28 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050309 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Paul References: <20050419225640.7B92816A4CF@hub.freebsd.org> In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:41:33 -0000 [skip] > - What should the script be called? wintobsd.sh sounds kind of lame. mkndisko.sh? =) > Any suggestions or comments on my mad scheme would be welcome. Is it possible to detect if the driver needs other files and prompt the user for this files' path (or assume a path to be looked for first) to copy it to /compat/ndis/ ? Ie, the user inputs /tmp/driver-foo_winxp-ver-bar/driver-foo.inf (same for sys) and the script tries to find the necessary files foo-a.bin and foo-b.bind under /tmp/driver-foo_winxp-ver-bar/ and copies it, or ask for the path if cant find it... -- Atenciosamente, Patrick Tracanelli FreeBSD Brasil LTDA. The FreeBSD pt_BR Documentation Project http://www.freebsdbrasil.com.br patrick @ freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-current@FreeBSD.ORG Tue Apr 19 15:39:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB23316A4CE for ; Tue, 19 Apr 2005 15:39:54 +0000 (GMT) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5037443D45 for ; Tue, 19 Apr 2005 15:39:54 +0000 (GMT) (envelope-from steve@virtual-voodoo.com) Received: from inlafsteve (bdsl.66.12.217.51.gte.net [66.12.217.51]) (authenticated bits=0) by energistic.com (8.13.3/8.13.3) with ESMTP id j3JFdm0q012617; Tue, 19 Apr 2005 10:39:50 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <001501c544f5$f6fc3fd0$9b00030a@officescape.net> From: "Steve Ames" To: "Eric Anderson" , "Steve Ames" References: <200504191530.j3JFUvWD030545@energistic.com> <42652533.8060106@centtech.com> Date: Tue, 19 Apr 2005 10:39:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_63, SPF_FAIL,USER_IN_WHITELIST_TO autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on energistic.com X-Mailman-Approved-At: Wed, 20 Apr 2005 11:44:59 +0000 cc: freebsd-current@freebsd.org Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 15:39:54 -0000 I'm trying that now. However on 5.x 'make kernel' installs a kernel.old. On 6.x: basement# make -n kernel cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x /usr/obj/usr/src/make.i386/make ]; then echo /usr/obj/usr/src/make.i386/make; else echo make; fi` -m /usr/src/share/mk -f Makefile.inc1 buildkernel cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x /usr/obj/usr/src/make.i386/make ]; then echo /usr/obj/usr/src/make.i386/make; else echo make; fi` -m /usr/src/share/mk -f Makefile.inc1 installkernel 'make kernel' executed both 'make buildkernel' and 'make installkernel' so I'm guessing it won't but I'll know for sure in a few minutes. -Steve ----- Original Message ----- From: "Eric Anderson" To: "Steve Ames" Cc: Sent: Tuesday, April 19, 2005 10:35 AM Subject: Re: kernel.old not used any longer? > Steve Ames wrote: > > I just noticed yesterday that there hasn't been an update to /boot/kernel.old > > since sometime in August. Yesterday was my first bad kernel on -CURRENT and > > I fell back to /boot/kernel.old/kernel and was suprised that it was that old. > > > > When did 'make kernel' stop copying /boot/kernel to /boot/kernel.old? It still > > seems to have that behavior on 5.X. I checked UPDATING but didn't see anything > > on this behavior change. Nor could I find a knob in make.conf. > > > > Is this user error somewhere? > > Using 'make buildkernel ...' and 'make installkernel ...' does the kernel.old > dance correctly. > > Eric > > > > -- > ------------------------------------------------------------------------ > Eric Anderson Sr. Systems Administrator Centaur Technology > A lost ounce of gold may be found, a lost moment of time never. > ------------------------------------------------------------------------ > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 03:43:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A44A616A4CE for ; Wed, 20 Apr 2005 03:43:37 +0000 (GMT) Received: from tamu-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2701343D2F for ; Wed, 20 Apr 2005 03:43:37 +0000 (GMT) (envelope-from tyler@neo.tamu.edu) Received: from xyzzy-5.tamu.edu (xyzzy-5.tamu.edu [165.91.22.29]) by tamu-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id j3K3hWuj057335; Tue, 19 Apr 2005 22:43:33 -0500 (CDT) Received: from neo.tamu.edu (localhost.tamu.edu [127.0.0.1]) by xyzzy-5.tamu.edu (8.12.9/8.12.9) with SMTP id j3K3hWxH092001; Tue, 19 Apr 2005 22:43:32 -0500 (CDT) (envelope-from tyler@neo.tamu.edu) Message-Id: <200504200343.j3K3hWxH092001@xyzzy-5.tamu.edu> Date: Wed, 20 Apr 2005 03:43:32 -0000 To: "Daniel O'Connor" , From: "Ballance, Robert T" X-Mailer: TWIG 2.6.2 In-Reply-To: <200504201221.39355.doconnor@gsoft.com.au> X-Client-IP: X-Mailman-Approved-At: Wed, 20 Apr 2005 11:44:59 +0000 Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tyler@neo.tamu.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 03:43:37 -0000 > > You still end up needing the C compiler, objcopy, ndiscvt and (optionally) > > iconv, but the script automates the use of all these tooks and explains > > to the user what's going on while it's working. > > It's certainly simpler than the current state of afairs and unless the kernel > NDIS grows the ability to directly read .sys & .inf files from your disk > (which would be very cool :) it's about a simple as it's going to get.. I think it's small enough as such, given that Project Evil isn't the only thing that needs a C compiler, and iconv...how much does Project Evil require that isn't in the base FreeBSD install anyways? > > - What should the script be called? wintobsd.sh sounds kind of lame. > > encappe > win2elf > pe2elf > exorcist.sh ;) ndisload.sh driverload.sh windriver.sh pureevil.sh >=] -R. Tyler Ballance ..and back to work.. From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 08:16:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4116016A4CE for ; Wed, 20 Apr 2005 08:16:33 +0000 (GMT) Received: from ns01.connect.az (ns02.connect.az [62.212.236.162]) by mx1.FreeBSD.org (Postfix) with SMTP id F3CCA43D5A for ; Wed, 20 Apr 2005 08:16:31 +0000 (GMT) (envelope-from tofik@oxygen.az) Received: (qmail 847 invoked from network); 20 Apr 2005 11:16:55 -0000 Received: from unknown (HELO ?192.168.0.10?) (192.168.0.10) by office.connect.az with SMTP; 20 Apr 2005 11:16:55 -0000 Message-ID: <42660FE2.7090406@oxygen.az> Date: Wed, 20 Apr 2005 13:16:34 +0500 From: tofik suleymanov User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damian Gerow References: <20050416154321.42E1243D58@mx1.FreeBSD.org> <42617480.5080903@oxygen.az> <20050417190534.GC51599@afflictions.org> In-Reply-To: <20050417190534.GC51599@afflictions.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Apr 2005 11:44:59 +0000 cc: freebsd-current@freebsd.org cc: Jeffrey Subject: Re: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 08:16:33 -0000 Damian Gerow wrote: >Thus spake Tofik Suleymanov (tofik@oxygen.az) [17/04/05 08:05]: >: >Does anyone know more about support for the promise fasttrak tx 4200? It >: >isn't in the current. >: >: We've got fasttrack tx2200 (the same chipset as 4400) and it not >: recognized at all on 5.3-RELEASE. >: I am also interested in any information about support of this hardware >: on RELENG_5. > >Have you tried applying the ATA mkIII patchset? I've been running with a >TX2200 for a month handling NFS (albeit, low volume) and the patchset >without any issues whatsoever, and the card is fully supported. > > I did apply the patch successfully,but yet couldnt manage to work two sata controllers in following scheme: let's say A - sata controller that comes on motherboard (works fine with generic kernel) B - tx2200 fasttrack on pci interface (doesnt work with generic,but works after Soren's mkIII patch) each sata controller has two drives attached in mirroring mode.So,we have two mirrors on each controller. If i boot with the patched kernel it sees my tx2200 fasttrack controller,but cant find root fs to continue loading.For some reason,raid array on motherboard sata controller doesnt seem to come up. Need to say,that mirror on motherboard controller is defined with common atacontrol,not the patched one.Maybe this is the reason of the problem ? From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:52:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C86616A4CE for ; Wed, 20 Apr 2005 11:52:41 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DECF43D53 for ; Wed, 20 Apr 2005 11:52:41 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3KBqeXq026561; Wed, 20 Apr 2005 04:52:40 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Apr 2005 04:52:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 20 Apr 2005 04:52:40 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C59237A@bcs-mail3.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cannot log on as root after upgrade Thread-Index: AcVFZVEucAQMkYCGSiuJEh+nK89dIQAOHpNJ From: "Li, Qing" To: "Andre Guibert de Bruet" X-OriginalArrivalTime: 20 Apr 2005 11:52:29.0923 (UTC) FILETIME=[6E19D330:01C5459F] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 cc: freebsd-current@freebsd.org Subject: RE: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:52:41 -0000 SSBndWVzcyBteSBwcm9ibGVtIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBwYW0NCmNvbmZpZ3Vy YXRpb24gYnV0IEkga25vdyBsaXR0bGUgb2YgcGFtLg0KIA0KSSBjb3VsZCBsb2cgaW4gYXMgYSBu b3JtYWwgdXNlciB0aGVuICJzdSIgc3VjY2Vzc2Z1bGx5Lg0KU28gSSB3ZW50IGludG8gL2V0Yy9w YW0uZCBhbmQgcmVtb3ZlZCBhbGwgb2YgdGhlIHNlcnZpY2VzDQpleGNlcHQgIm90aGVyIiwgYW5k IGFmdGVyIGEgcmVib290IEkgY291bGQgbG9nIGluIGFzDQpyb290Lg0KIA0KVGhhbmtzLA0KIA0K LS0gUWluZw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQW5kcmUgR3Vp YmVydCBkZSBCcnVldCBbbWFpbHRvOmFuZHlAc2lsaWNvbmxhbmRtYXJrLmNvbV0gDQoJU2VudDog VHVlIDQvMTkvMjAwNSA5OjU2IFBNIA0KCVRvOiBMaSwgUWluZyANCglDYzogZnJlZWJzZC1jdXJy ZW50QGZyZWVic2Qub3JnIA0KCVN1YmplY3Q6IFJFOiBjYW5ub3QgbG9nIG9uIGFzIHJvb3QgYWZ0 ZXIgdXBncmFkZQ0KCQ0KCQ0KDQoNCglPbiBUdWUsIDE5IEFwciAyMDA1LCBMaSwgUWluZyB3cm90 ZToNCgkNCgk+IEkgY3ZzJ2QgYWJvdXQgNyBob3VycyBhZ28gYW5kIGJ1aWxkIHdvcmxkIHRvb2sg YSB3aGlsZSAuLi4NCgk+DQoJPiBNeSBwcmV2aW91cyBzeXN0ZW0gd2FzIGFsc28gNi4wLUNVUlJF TlQgdGhhdCB3YXMNCgk+IGN2cydkIGFib3V0IGEgbW9udGggYWdvLg0KCQ0KCVRoZSBnZW5lcmlj IHBhdGggZm9yIHJlY292ZXJ5IGlzIGFzIGZvbGxvd3M6DQoJDQoJLSBCb290IHVwIGluIHNpbmds ZSB1c2VyIG1vZGUuDQoJLSBNYW51YWxseSBjb25maWd1cmUgbmV0d29yayBpbnRlcmZhY2Uocyku DQoJLSBjdnN1cCBhZ2Fpbi4NCgktICJtYWtlIHdvcmxkIiBpbiAvdXNyL3NyYywgc3RpbGwgaW4g c2luZ2xlLXVzZXIgbW9kZS4NCgktIG1lcmdlbWFzdGVyIC1pDQoJLSBib290IGludG8gbXVsdGkt dXNlciBtb2RlLg0KCQ0KCUdpdmUgdGhhdCBhIHdoaXJsLi4uDQoJDQoJQW5keQ0KCQ0KCXwgQW5k cmUgR3VpYmVydCBkZSBCcnVldCB8IEVudGVycHJpc2UgU29mdHdhcmUgQ29uc3VsdGFudCA+DQoJ fCBTaWxpY29uIExhbmRtYXJrLCBMTEMuIHwgaHR0cDovL3NpbGljb25sYW5kbWFyay5jb20vICAg ID4NCgkNCgkNCg0K From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 12:28:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B47FF16A4CE for ; Wed, 20 Apr 2005 12:28:18 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA7A43D2D for ; Wed, 20 Apr 2005 12:28:18 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id j3KCSIr4027805 for ; Wed, 20 Apr 2005 05:28:18 -0700 (PDT) Received: from bcs-mail3.bluecoat.com ([10.2.2.59]) by bcs-mail.bluecoat.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Apr 2005 05:28:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 20 Apr 2005 05:28:17 -0700 Message-ID: <48D44BB27BDE3840BDF18E59CB169A5C59237B@bcs-mail3.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: repeating keystrokes Thread-Index: AcVFpG47gKHx9jMrTx2YKcR6EmhjUg== From: "Li, Qing" To: X-OriginalArrivalTime: 20 Apr 2005 12:28:07.0395 (UTC) FILETIME=[68222B30:01C545A4] X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: repeating keystrokes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 12:28:18 -0000 SSBhbSBzZWVpbmcga2V5c3Ryb2tlcyBhcmUgYmVpbmcgcmVwZWF0ZWQgYSBsb3Qgd2l0aCB0aGUN CmJ1aWxkIG9mIHRoZSBsYXRlc3QgY3ZzLiBJIGRvIHJlbWVtYmVyIHJlYWRpbmcgZW1haWxzDQph Ym91dCB0aGUgc2FtZSBpc3N1ZSBhIGRheSBvciB0d28gYWdvIGZyb20gc29tZW9uZSBidXQNCkkg Zm9yZ290IG9uIHdoaWNoIGxpc3QuDQogDQpJcyBhbnlvbmUgZWxzZSBzZWVpbmcgdGhpcyBwcm9i bGVtPw0KIA0KSSdtIHJ1bm5pbmcgNi4wLWN1cnJlbnQgb24gYSBEZWxsIExhdGl0dWRlIEQ2MDAg bGFwdG9wLg0KIA0KLS0gUWluZw0KIA0K From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 11:52:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC7816A4CE for ; Wed, 20 Apr 2005 11:52:29 +0000 (GMT) Received: from ns01.connect.az (ns02.connect.az [62.212.236.162]) by mx1.FreeBSD.org (Postfix) with SMTP id D1CEF43D60 for ; Wed, 20 Apr 2005 11:52:27 +0000 (GMT) (envelope-from tofik@oxygen.az) Received: (qmail 25483 invoked from network); 20 Apr 2005 14:52:52 -0000 Received: from unknown (HELO ?192.168.0.10?) (192.168.0.10) by office.connect.az with SMTP; 20 Apr 2005 14:52:52 -0000 Message-ID: <4266427B.1020203@oxygen.az> Date: Wed, 20 Apr 2005 16:52:27 +0500 From: tofik suleymanov User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tofik suleymanov References: <20050416154321.42E1243D58@mx1.FreeBSD.org> <42617480.5080903@oxygen.az> <20050417190534.GC51599@afflictions.org> <42660FE2.7090406@oxygen.az> In-Reply-To: <42660FE2.7090406@oxygen.az> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Apr 2005 12:30:07 +0000 cc: Damian Gerow cc: freebsd-current@freebsd.org cc: Jeffrey Subject: Re: promise fasttrak tx 4200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 11:52:29 -0000 tofik suleymanov wrote: > Damian Gerow wrote: > >> Thus spake Tofik Suleymanov (tofik@oxygen.az) [17/04/05 08:05]: >> : >Does anyone know more about support for the promise fasttrak tx >> 4200? It >> : >isn't in the current. >> : >> : We've got fasttrack tx2200 (the same chipset as 4400) and it not : >> recognized at all on 5.3-RELEASE. >> : I am also interested in any information about support of this >> hardware : on RELENG_5. >> >> Have you tried applying the ATA mkIII patchset? I've been running >> with a >> TX2200 for a month handling NFS (albeit, low volume) and the patchset >> without any issues whatsoever, and the card is fully supported. >> >> sorry,a typo "So,we have two mirrors on each controller." -> "So,we have two mirrors total: one mirror on each controller." I From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 12:57:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F03116A4CE; Wed, 20 Apr 2005 12:57:16 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD5843D53; Wed, 20 Apr 2005 12:57:16 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 589712C4AF; Wed, 20 Apr 2005 14:57:14 +0200 (CEST) Date: Wed, 20 Apr 2005 14:57:14 +0200 From: Thomas Quinot To: Bill Paul Message-ID: <20050420125714.GE12555@melusine.cuivre.fr.eu.org> References: <20050419225640.7B92816A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050419225640.7B92816A4CF@hub.freebsd.org> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 12:57:16 -0000 * Bill Paul, 2005-04-20 : > Any suggestions or comments on my mad scheme would be welcome. I like being able to give a sensible name to ndiscvt'd drivers (eg iwe instead of ndis for Intel Wireless Ethernet cards). Currently this requires both using the -n argument to ndiscvt and overriding the module name in the if_ndis Makefile. It would be nice if this was made a little easier. Thomas. From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 13:10:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A79B16A4CE for ; Wed, 20 Apr 2005 13:10:44 +0000 (GMT) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B0E43D3F for ; Wed, 20 Apr 2005 13:10:42 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from tablet.dino.sk ([213.215.72.59]) (AUTH: PLAIN milan) by bsd.dino.sk with esmtp; Wed, 20 Apr 2005 15:11:59 +0200 id 000000FD.4266551F.00004AB0 From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 20 Apr 2005 15:10:09 +0200 User-Agent: KMail/1.7.2 References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420125714.GE12555@melusine.cuivre.fr.eu.org> In-Reply-To: <20050420125714.GE12555@melusine.cuivre.fr.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504201510.10557.bsd@dino.sk> Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 13:10:44 -0000 On Wednesday 20 April 2005 14:57, Thomas Quinot wrote: > * Bill Paul, 2005-04-20 : > > Any suggestions or comments on my mad scheme would be welcome. > > I like being able to give a sensible name to ndiscvt'd drivers (eg iwe > instead of ndis for Intel Wireless Ethernet cards). Currently this > requires both using the -n argument to ndiscvt and overriding the module > name in the if_ndis Makefile. It would be nice if this was made a little > easier. > > Thomas. > While native solution would be nice, I think this could be easily accomplished with interface renaming (ifconfig ndis0 name iwe0). Milan From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 14:04:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62FC816A4CE; Wed, 20 Apr 2005 14:04:11 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1140C43D60; Wed, 20 Apr 2005 14:04:10 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id D0AD61F1C0; Wed, 20 Apr 2005 16:04:09 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id B2543641C; Wed, 20 Apr 2005 16:04:09 +0200 (CEST) Date: Wed, 20 Apr 2005 16:04:09 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050420140409.GA77731@stack.nl> References: <20050418092550.GA97539@stack.nl> <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20050419204723.GG1157@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 14:04:11 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote: > This compiles. It does and it seems to work. The NFS performance drops considerably though, from 8/9 MByte/s to 3/4 on sequential reads for instance. kern/79208 is fixed by this indeed, in that I get short writes (in case of my test server at 1802240+ bytes, so './writev 2 foo' fails... Marc --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZmFZezjnobFOgrERArNtAKC4NvqjLns4i6/ze5g2mtoefl0byQCfZ9Ih a6KDrtrCOjFgVqA/1g5SFC8= =m8tu -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 14:26:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8838516A4CE; Wed, 20 Apr 2005 14:26:35 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KEOnN9071973; Wed, 20 Apr 2005 10:24:49 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KEOmwc071972; Wed, 20 Apr 2005 10:24:48 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 10:24:48 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050420142448.GH1157@green.homeunix.org> References: <20050418092752.GB97539@stack.nl> <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420140409.GA77731@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 14:26:35 -0000 On Wed, Apr 20, 2005 at 04:04:09PM +0200, Marc Olzheim wrote: > On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote: > > This compiles. > > It does and it seems to work. The NFS performance drops considerably > though, from 8/9 MByte/s to 3/4 on sequential reads for instance. > > kern/79208 is fixed by this indeed, in that I get short writes (in case > of my test server at 1802240+ bytes, so './writev 2 foo' fails... Performance drops in what cases? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 14:38:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4D4F16A4CE; Wed, 20 Apr 2005 14:38:44 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32ED43D4C; Wed, 20 Apr 2005 14:38:43 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 1090D1F19A; Wed, 20 Apr 2005 16:38:43 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id D94BB6583; Wed, 20 Apr 2005 16:38:42 +0200 (CEST) Date: Wed, 20 Apr 2005 16:38:42 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050420143842.GB77731@stack.nl> References: <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <20050420142448.GH1157@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 14:38:44 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote: > > It does and it seems to work. The NFS performance drops considerably > > though, from 8/9 MByte/s to 3/4 on sequential reads for instance. > >=20 > > kern/79208 is fixed by this indeed, in that I get short writes (in case > > of my test server at 1802240+ bytes, so './writev 2 foo' fails... >=20 > Performance drops in what cases? Hmm, seems only to happen in large sequential reads... It might just be the FreeBSD 4.6 NFS server that is the problem though. I've had more NFS troubles with it. Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Marc --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZmlyezjnobFOgrERAshmAJ45uor6Jz6tuOrKt20hozLTMDnPbACePn+5 ZE3M6Au5bLATSF+rP5JuuIY= =ufVf -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 15:22:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 27EE916A4CE; Wed, 20 Apr 2005 15:22:27 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KFKdre072379; Wed, 20 Apr 2005 11:20:39 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KFKcc0072378; Wed, 20 Apr 2005 11:20:38 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 11:20:38 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050420152038.GI1157@green.homeunix.org> References: <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420143842.GB77731@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 15:22:27 -0000 On Wed, Apr 20, 2005 at 04:38:42PM +0200, Marc Olzheim wrote: > On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote: > > > It does and it seems to work. The NFS performance drops considerably > > > though, from 8/9 MByte/s to 3/4 on sequential reads for instance. > > > > > > kern/79208 is fixed by this indeed, in that I get short writes (in case > > > of my test server at 1802240+ bytes, so './writev 2 foo' fails... > > > > Performance drops in what cases? > > Hmm, seems only to happen in large sequential reads... It might just be > the FreeBSD 4.6 NFS server that is the problem though. I've had more NFS > troubles with it. Reads should be totally unaffected... > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 15:35:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B83716A4CE; Wed, 20 Apr 2005 15:35:30 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A6F43D45; Wed, 20 Apr 2005 15:35:29 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id E90991F1C7; Wed, 20 Apr 2005 17:35:28 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id CD0DD6583; Wed, 20 Apr 2005 17:35:28 +0200 (CEST) Date: Wed, 20 Apr 2005 17:35:28 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050420153528.GC77731@stack.nl> References: <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL" Content-Disposition: inline In-Reply-To: <20050420152038.GI1157@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 15:35:30 -0000 --iFRdW5/EC4oqxDHL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: > Reads should be totally unaffected... The server was misbehaving. Fixed. :-) > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > > writes on regular files... ? >=20 > Our manpage is incorrect; POSIX states that they are (see earlier > e-mail). There really is no alternative -- we simply can't build > an NFS transaction larger than our buffer cache can accomodate. > Note that short wries won't happen for normal buffer sizes, only > excessively large ones. I really don't believe that writev() is meant > to be used so that you can write gigantic data structures in a single > transaction... Ah, I was reading the SUSv2 page: http://www.opengroup.org/onlinepubs/009695399/functions/write.html instead of the POSIX version. But in neither of those I can extrude the fact that it can return with result < nbyte, without it being a permanent condition. What phrase makes you conclude that it can ? Marc --iFRdW5/EC4oqxDHL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZnbAezjnobFOgrERAqYEAJ9a25uCceVtDReKpiAUkMsNi0h5fACeJvTc dpl7Dp6Sa4k3Bth3VKt/hR0= =qmxF -----END PGP SIGNATURE----- --iFRdW5/EC4oqxDHL-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 15:54:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A495316A4CE; Wed, 20 Apr 2005 15:54:22 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KFqXoh072666; Wed, 20 Apr 2005 11:52:33 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KFqXqZ072665; Wed, 20 Apr 2005 11:52:33 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 11:52:33 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050420155233.GJ1157@green.homeunix.org> References: <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420153528.GC77731@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 15:54:23 -0000 On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: > On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: > > Reads should be totally unaffected... > > The server was misbehaving. Fixed. :-) > > > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > > > writes on regular files... ? > > > > Our manpage is incorrect; POSIX states that they are (see earlier > > e-mail). There really is no alternative -- we simply can't build > > an NFS transaction larger than our buffer cache can accomodate. > > Note that short wries won't happen for normal buffer sizes, only > > excessively large ones. I really don't believe that writev() is meant > > to be used so that you can write gigantic data structures in a single > > transaction... > > Ah, I was reading the SUSv2 page: > > http://www.opengroup.org/onlinepubs/009695399/functions/write.html > > instead of the POSIX version. > > But in neither of those I can extrude the fact that it can return > with result < nbyte, without it being a permanent condition. > What phrase makes you conclude that it can ? This specific issue is not clear-cut; the best thing to do lies somewhere within the range of these scenarios: "If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes would give a failure return (except as noted below)." "When attempting to write to a file descriptor (other than a pipe or FIFO) that supports non-blocking writes and cannot accept the data immediately: * If the O_NONBLOCK flag is clear, write() shall block the calling thread until the data can be accepted. * If the O_NONBLOCK flag is set, write() shall not block the thread. If some data can be written without blocking the thread, write() shall write what it can and return the number of bytes written. Otherwise, it shall return -1 and set errno to [EAGAIN]." "[ENOBUFS] Insufficient resources were available in the system to perform the operation." I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more "than there is room for." -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 16:12:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E731E16A4E7; Wed, 20 Apr 2005 16:12:22 +0000 (GMT) In-Reply-To: <20050420023351.C421@xorpc.icir.org> from Luigi Rizzo at "Apr 20, 2005 02:33:51 am" To: rizzo@icir.org (Luigi Rizzo) Date: Wed, 20 Apr 2005 16:12:22 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050420161222.E731E16A4E7@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 16:12:25 -0000 > On Wed, Apr 20, 2005 at 05:22:40AM +0000, Bill Paul wrote: > ... > > > What about if you want to use >1 NDIS driver? How will it avoid symbol name > > > collisions? > > i don't understand the issue of name collisions though. > Assuming that things work in the same way as dlopen() > (which seems to be the case according to the documentation) > the symbols in the module that we kldload are not globally > visible, but keyed by fileid and only accessible through > kldsym(). So the collisions are only in the filenames that > we kldload, not in the individual symbols. > Then it suffices to rename the patched files... > > cheers > luigi Part of the module build mechanism turns all symbols within a .ko static, so they aren't visible to other modules unless they have an explicit dependency (MODULE_DEPENDS()). For this case, it happens that all of windrv_stub.c's code and data are declared static anyway, so multiple foo_sys.ko modules can't collide with each other. The only thing that is a problem is using MODULE_VERSION(foo, 1). The kernel will complain if you try to load a module of type "foo,1" when there's already a "foo,1" module present. This prevents you from confusing the kernel by doing: # kldload ./foo.ko # cp foo.ko bar.ko # kldload ./bar.ko If foo.c has MODULE_VERSION(foo, 1) in it, then the kernel will know that bar.ko is just another copy of foo.ko even though the file name is different. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 17:08:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id CF8AE16A4CF; Wed, 20 Apr 2005 17:08:02 +0000 (GMT) In-Reply-To: <42663FE8.7070906@freebsdbrasil.com.br> from Patrick Tracanelli at "Apr 20, 2005 08:41:28 am" To: eksffa@freebsdbrasil.com.br (Patrick Tracanelli) Date: Wed, 20 Apr 2005 17:08:02 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050420170802.CF8AE16A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:08:02 -0000 > [skip] > > > - What should the script be called? wintobsd.sh sounds kind of lame. > > mkndisko.sh? =) > > > Any suggestions or comments on my mad scheme would be welcome. > > Is it possible to detect if the driver needs other files and prompt the > user for this files' path (or assume a path to be looked for first) to > copy it to /compat/ndis/ ? > > Ie, the user inputs /tmp/driver-foo_winxp-ver-bar/driver-foo.inf (same > for sys) and the script tries to find the necessary files foo-a.bin and > foo-b.bind under /tmp/driver-foo_winxp-ver-bar/ and copies it, or ask > for the path if cant find it... The way Microsoft does it, the .inf is supposed to tell the installer about all the files included in the distribution which have to be copied into C:\WINNT\SYSTEM32. This includes any firmware images or additional files that have to be loaded via NdisOpenFile(). Doing this in Project Evil would require a much more sophisticated .inf file parser. The existing parser in ndiscvt(8) is only smart enough to extract the registry keys and device ID info. It could be made smarter, but I think this is a project for another day. For now, I will probably just have the script ask the user if he/she has any additionaly firmware images that need to be processed. Note that there are actually two methods for getting firmware files loaded. The simple method is to copy them to /compat/ndis and just let NdisOpenFile() grab them, but this only works if you kldload your driver after the system is up and running multiuser. If you pre-load the driver via /boot/loader.conf, this will fail: during initial kernel bootstrap, the filesystems aren't mounted yet. So in that scenario, you need the second method, which is to convert the firmware file into a .ko and pre-load that along with the driver. This conversion process is much simpler: the file is packaged up using objcopy(1) and the turned into a shared object with ld(1). Once the file is kldloaded or pre-loaded, NdisOpenFile() is smart enough to find it by scanning the loaded module list. A similar trick can also be used to link the firmware .o and the driver .o into a static kernel image. (This is mostly handled by the -f flag to ndiscvt(8).) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 17:12:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC5E616A4CE; Wed, 20 Apr 2005 17:12:22 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB3D43D1D; Wed, 20 Apr 2005 17:12:21 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mailhost.stack.nl (Postfix) with ESMTP id B84A61F1CD; Wed, 20 Apr 2005 19:12:20 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id AA0B71CEAA; Wed, 20 Apr 2005 19:12:20 +0200 (CEST) Date: Wed, 20 Apr 2005 19:12:20 +0200 From: Jilles Tjoelker To: Brian Fundakowski Feldman Message-ID: <20050420171220.GB93623@stack.nl> References: <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420155233.GJ1157@green.homeunix.org> X-Operating-System: FreeBSD 5.3-RELEASE-p9 i386 User-Agent: Mutt/1.5.6i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:12:23 -0000 On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote: > On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: > > On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: > > > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > > > > writes on regular files... ? > > > Our manpage is incorrect; POSIX states that they are (see earlier > > > e-mail). There really is no alternative -- we simply can't build > > > an NFS transaction larger than our buffer cache can accomodate. > > > Note that short wries won't happen for normal buffer sizes, only > > > excessively large ones. I really don't believe that writev() is meant > > > to be used so that you can write gigantic data structures in a single > > > transaction... It is ok to return partial success if the first chunk of a large write succeeded and a later chunk failed persistently, but not if it cannot be performed as a single NFS transaction. > > Ah, I was reading the SUSv2 page: > > http://www.opengroup.org/onlinepubs/009695399/functions/write.html > > instead of the POSIX version. > > But in neither of those I can extrude the fact that it can return > > with result < nbyte, without it being a permanent condition. > > What phrase makes you conclude that it can ? > This specific issue is not clear-cut; the best thing to do lies somewhere > within the range of these scenarios: > "If a write() requests that more bytes be written than there is room > for (for example, [XSI] [Option Start] the process' file size limit > or [Option End] the physical end of a medium), only as many bytes as > there is room for shall be written. For example, suppose there is > space for 20 bytes more in a file before reaching a limit. A write of > 512 bytes will return 20. The next write of a non-zero number of bytes > would give a failure return (except as noted below)." This only applies to permanent conditions. > "When attempting to write to a file descriptor (other than a pipe or > FIFO) that supports non-blocking writes and cannot accept the data > immediately: > * If the O_NONBLOCK flag is clear, write() shall block the calling > thread until the data can be accepted. > * If the O_NONBLOCK flag is set, write() shall not block the > thread. If some data can be written without blocking the thread, > write() shall write what it can and return the number of bytes > written. Otherwise, it shall return -1 and set errno to [EAGAIN]." I think regular files do not support non-blocking writes, even if they are on NFS; in any case, O_NONBLOCK is disabled by default. > "[ENOBUFS] Insufficient resources were available in the system to > perform the operation." > I think the first is more useful behavior than the last. Supporting it > should be exactly the same as supporting what happens if the actual > filesystem fills up. In this case, the filesystem is being requested to > write more "than there is room for." The filesystem filling up is a totally different case as attempting the rest of the write is futile in that case. In a lot of code, a short write() is treated as a (fairly) persistent error. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 17:30:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CCC3316A4CE; Wed, 20 Apr 2005 17:30:32 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KHSew1073163; Wed, 20 Apr 2005 13:28:40 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KHSei8073162; Wed, 20 Apr 2005 13:28:40 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 13:28:39 -0400 From: Brian Fundakowski Feldman To: Jilles Tjoelker Message-ID: <20050420172839.GK1157@green.homeunix.org> References: <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <20050420171220.GB93623@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420171220.GB93623@stack.nl> User-Agent: Mutt/1.5.6i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:30:33 -0000 On Wed, Apr 20, 2005 at 07:12:20PM +0200, Jilles Tjoelker wrote: > On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote: > > On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: > > > On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: > > > > > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > > > > > writes on regular files... ? > > > > > Our manpage is incorrect; POSIX states that they are (see earlier > > > > e-mail). There really is no alternative -- we simply can't build > > > > an NFS transaction larger than our buffer cache can accomodate. > > > > Note that short wries won't happen for normal buffer sizes, only > > > > excessively large ones. I really don't believe that writev() is meant > > > > to be used so that you can write gigantic data structures in a single > > > > transaction... > > It is ok to return partial success if the first chunk of a large write > succeeded and a later chunk failed persistently, but not if it cannot be > performed as a single NFS transaction. What is your rationale for this? > > > Ah, I was reading the SUSv2 page: > > > > http://www.opengroup.org/onlinepubs/009695399/functions/write.html > > > > instead of the POSIX version. > > > > But in neither of those I can extrude the fact that it can return > > > with result < nbyte, without it being a permanent condition. > > > What phrase makes you conclude that it can ? > > > This specific issue is not clear-cut; the best thing to do lies somewhere > > within the range of these scenarios: > > > "If a write() requests that more bytes be written than there is room > > for (for example, [XSI] [Option Start] the process' file size limit > > or [Option End] the physical end of a medium), only as many bytes as > > there is room for shall be written. For example, suppose there is > > space for 20 bytes more in a file before reaching a limit. A write of > > 512 bytes will return 20. The next write of a non-zero number of bytes > > would give a failure return (except as noted below)." > > This only applies to permanent conditions. > > > "When attempting to write to a file descriptor (other than a pipe or > > FIFO) that supports non-blocking writes and cannot accept the data > > immediately: > > > * If the O_NONBLOCK flag is clear, write() shall block the calling > > thread until the data can be accepted. > > > * If the O_NONBLOCK flag is set, write() shall not block the > > thread. If some data can be written without blocking the thread, > > write() shall write what it can and return the number of bytes > > written. Otherwise, it shall return -1 and set errno to [EAGAIN]." > > I think regular files do not support non-blocking writes, even if they > are on NFS; in any case, O_NONBLOCK is disabled by default. POSIX does not specify O_NONBLOCK semantics for regular files. This means we can do whatever is most useful. > > "[ENOBUFS] Insufficient resources were available in the system to > > perform the operation." > > > I think the first is more useful behavior than the last. Supporting it > > should be exactly the same as supporting what happens if the actual > > filesystem fills up. In this case, the filesystem is being requested to > > write more "than there is room for." > > The filesystem filling up is a totally different case as attempting the > rest of the write is futile in that case. No, it isn't. The filesystem may be not-full again soon, possibly even what the program might consider "immediately". > In a lot of code, a short write() is treated as a (fairly) persistent > error. I mentioned this several e-mails ago. Plenty of software is also not going to understand ENOBUFS. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 18:01:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 99BA516A4CE; Wed, 20 Apr 2005 18:01:39 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3KHxkSc073470; Wed, 20 Apr 2005 13:59:46 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3KHxkf5073469; Wed, 20 Apr 2005 13:59:46 -0400 (EDT) (envelope-from green) Date: Wed, 20 Apr 2005 13:59:46 -0400 From: Brian Fundakowski Feldman To: Garrett Wollman Message-ID: <20050420175946.GL1157@green.homeunix.org> References: <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <16998.37222.529748.205885@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16998.37222.529748.205885@khavrinen.csail.mit.edu> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 18:01:40 -0000 On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote: > < said: > > > I think the first is more useful behavior than the last. Supporting it > > should be exactly the same as supporting what happens if the actual > > filesystem fills up. In this case, the filesystem is being requested to > > write more "than there is room for." > > Returning a short write for operations on regular files would > definitely be considered astonishing. The changes that you have made > should be considered flow control, not admission control, and should > appear to the user no differently than if we were waiting for a slow > disk to write something; i.e., the user thread should be blocked until > either the entire write completes, or the process is interrupted by a > signal. So what _would_ be consistent for nfs_bio.c::nfs_write()? IO_UNIT is set for all write calls which means "atomic", and nfs_rslock() and O_APPEND appear to at least attempt this. Please take a detailed look at the current system and the changes... it's far less clear-cut than POLA dictates. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 18:03:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B414116A4CE; Wed, 20 Apr 2005 18:03:33 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66D5343D2F; Wed, 20 Apr 2005 18:03:33 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 763AF1F062; Wed, 20 Apr 2005 20:03:32 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 58D926583; Wed, 20 Apr 2005 20:03:32 +0200 (CEST) Date: Wed, 20 Apr 2005 20:03:32 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050420180332.GC99695@stack.nl> References: <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <20050420171220.GB93623@stack.nl> <20050420172839.GK1157@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <20050420172839.GK1157@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org cc: Jilles Tjoelker Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 18:03:33 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 01:28:39PM -0400, Brian Fundakowski Feldman wrote: > > It is ok to return partial success if the first chunk of a large write > > succeeded and a later chunk failed persistently, but not if it cannot be > > performed as a single NFS transaction. >=20 > What is your rationale for this? Probably the part that you quoted about the write() after the short write() supposedly returning an error. Besides from that: since it isn't non-blocking, why not just block until everything is written ? That's the way it is done on FreeBSD 4.x and that's how I interpret the standards... Marc --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZpl0ezjnobFOgrERAmC1AKCoq4z0NDZ51FqUJYn8gtm6i7mkkACgyC67 Pgy9gPSlOR+D9vEC5vxVX74= =09w3 -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 19:09:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A3516A4CE for ; Wed, 20 Apr 2005 19:09:30 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1909943D41 for ; Wed, 20 Apr 2005 19:09:30 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from COMETE (pasteur-1-82-67-68-158.fbx.proxad.net [82.67.68.158]) by postfix4-2.free.fr (Postfix) with SMTP id 362993193A8 for ; Wed, 20 Apr 2005 21:09:28 +0200 (CEST) Message-ID: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> From: "Damien Bergamini" To: Date: Wed, 20 Apr 2005 21:08:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: New wireless drivers committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 19:09:30 -0000 I've recently imported four new wireless drivers into the tree: ipw(4) - driver for Intel PRO/Wireless 2100 adapters (MiniPCI). iwi(4) - driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI or MiniPCI). ral(4) - driver for Ralink RT2500 wireless adapters (PCI or CardBus). ural(4) - driver for Ralink RT2500USB wireless USB 2.0 adapters. ipw(4) and iwi(4) both require firmwares to operate. These firmwares can't be redistributed with the base system due to license restrictions. See firmware licensing terms here: http://ipw2100.sourceforge.net/firmware.php?fid=4 Ports which include the firmware images as well as the firmware loader are being worked on. A rather complete list of adapters supported by ral(4) and ural(4) can be found here: http://ralink.rapla.net/ The drivers have some known limitations: ipw(4) - HostAP mode is not supported due to firmware limitations. WPA (802.11i) support is being worked on. iwi(4) - IBSS support is not yet implemented. Monitor and HostAP modes are not supported due to firmware limitations. WPA (802.11i) support is being worked on. ral(4) - WEP, TKIP and CCMP hardware encryption is not yet supported (encryption is currently done by software). ural(4) - Does not support automatic adaptation of the transmit speed. Any feedback would be greatly appreciated. -- Damien From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 20:03:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E074316A4CE for ; Wed, 20 Apr 2005 20:03:46 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id F345C43D2D for ; Wed, 20 Apr 2005 20:03:45 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: from cc.bashibuzuk.net (pha75-4-82-66-87-70.fbx.proxad.net [82.66.87.70]) by postfix3-1.free.fr (Postfix) with ESMTP id 99CAA17355F for ; Wed, 20 Apr 2005 22:03:43 +0200 (CEST) Received: from cc.bashibuzuk.net (localhost [127.0.0.1]) by cc.bashibuzuk.net (8.13.1/8.13.1) with ESMTP id j3KK3pOB040498 for ; Wed, 20 Apr 2005 22:03:51 +0200 (CEST) (envelope-from yb@bashibuzuk.net) Received: (from yb@localhost) by cc.bashibuzuk.net (8.13.1/8.13.1/Submit) id j3KK3p7l040497 for freebsd-current@freebsd.org; Wed, 20 Apr 2005 22:03:51 +0200 (CEST) (envelope-from yb@bashibuzuk.net) X-Authentication-Warning: cc.bashibuzuk.net: yb set sender to yb@bashibuzuk.net using -f Date: Wed, 20 Apr 2005 22:03:51 +0200 From: Yann Berthier To: freebsd-current@freebsd.org Message-ID: <20050420200351.GV76080@bashibuzuk.net> Mail-Followup-To: freebsd-current@freebsd.org References: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> X-Operating-System: FreeBSD 6.0-CURRENT User-Agent: Mutt/1.5.9i Subject: Re: New wireless drivers committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 20:03:47 -0000 On Wed, 20 Apr 2005, Damien Bergamini wrote: > I've recently imported four new wireless drivers into the tree: Yeeha :) > ipw(4) and iwi(4) both require firmwares to operate. > These firmwares can't be redistributed with the base system due to > license restrictions. See firmware licensing terms here: > http://ipw2100.sourceforge.net/firmware.php?fid=4 > Ports which include the firmware images as well as the firmware loader > are being worked on. If I may ask: is the firmware not 'autoloaded' on OpenBSD by the driver itself ? If so, what's wrong with this approach ? > iwi(4) - IBSS support is not yet implemented. > Monitor and HostAP modes are not supported due to firmware ^^^^^^^ that's unfortunate Many thanks indeed ! - yann From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 20:06:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D49CB16A4CE for ; Wed, 20 Apr 2005 20:06:15 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A653043D49 for ; Wed, 20 Apr 2005 20:06:14 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOLMw-0002uG-F0 for freebsd-current@freebsd.org; Wed, 20 Apr 2005 22:00:18 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Apr 2005 22:00:18 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Apr 2005 22:00:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Wed, 20 Apr 2005 13:04:08 -0700 Lines: 75 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.8.2 Sender: news Subject: LOR/page fault panic vfs_mountroot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 20:06:16 -0000 Current as of a few minutes ago. LOR/panic. Dual processor box. kernel has vlan, ipfw, and dummynet enabled, but this doesn't look like the problem. Curiously, booting single user and mounting root there doesn't panic, but it does panic if you try to 'exit' to multiuser. [...] Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging disabled ad0: 19092MB at ata0-master UDMA33 acd0: CDROM at ata1-master UDMA33 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a lock order reversal 1st 0xc0a2d740 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/kern/vfs_bio.c:1485 2nd 0xc25e4d6c vnode interlock (vnode interlock) @ /usr/src/sys/kern/vfs_subr.c:1992 KDB: stack backtrace: kdb_backtrace(c090b56b,c25e4d6c,c09107f7,c09107f7,c09106c6) at kdb_backtrace+0x2e witness_checkorder(c25e4d6c,9,c09106c6,7c8,c229f480) at witness_checkorder+0x6aa _mtx_lock_flags(c25e4d6c,0,c09106c6,7c8,c105c294) at _mtx_lock_flags+0x8a vdrop(c25e4cf0,1,c09242b5,265,c10a74d8) at vdrop+0x32 vm_page_remove(c10a74d8,1,c09242b5,3f1,125) at vm_page_remove+0x11f vm_page_free_toq(c10a74d8,40,c10a74d8,e35dd870,c06e2978) at vm_page_free_toq+0xb0 vm_page_free(c10a74d8,0,c090edfb,5cd,d633a050) at vm_page_free+0x22 vfs_vmio_release(d633a050,0,c090edfb,511,0) at vfs_vmio_release+0xc8 brelse(d633a050,c25fb000,800,0,c229d180) at brelse+0x56d ffs_mountfs(c25e4cf0,c25af400,c229f480,0,0) at ffs_mountfs+0x668 ffs_mount(c25af400,c229f480,c246f690,c229f480,e35ddaa0) at ffs_mount+0xbfa vfs_domount(c229f480,c246f6c0,c246f690,4001,c246f7e0) at vfs_domount+0x667 vfs_donmount(c229f480,4001,e35ddbec,c259c600,6) at vfs_donmount+0x107 kernel_mount(c246faf0,4001,c25ed800,ffffffff) at kernel_mount+0x7e kernel_vmount(4001,c091012d,c25a8040,c0910134,c090b380) at kernel_vmount+0x4d vfs_mountroot_try(c246f910,c229ede4,c065a410,0,e35ddd00) at vfs_mountroot_try+0x13c vfs_mountroot(c09d1620,1,c0903906,206,0) at vfs_mountroot+0xd4 start_init(0,e35ddd38,c0904fe9,30d,0) at start_init+0x64 fork_exit(c065a410,0,e35ddd38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35ddd6c, ebp = 0 --- Pre-seeding PRNG: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0x4ac0c092 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0703f88 stack pointer = 0x28:0xe5092b78 frame pointer = 0x28:0xe5092b78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 73 (sysctl) [thread pid 73 tid 100060 ] Stopped at strlen+0x8: cmpb $0,0(%edx) db> show alllocks Process 73 (sysctl) thread 0xc23b2600 (100060) exclusive sx sysctl lock r = 0 (0xc09d1c60) locked @ /usr/src/sys/kern/kern_sysctl.c:1335 exclusive sleep mutex Giant r = 0 (0xc09d1620) locked @ /usr/src/sys/kern/kern_sysctl.c:1273 -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 20:06:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC39E16A4CF for ; Wed, 20 Apr 2005 20:06:35 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F45F43D31 for ; Wed, 20 Apr 2005 20:06:35 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 0EB185DA3; Wed, 20 Apr 2005 16:06:35 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75327-02; Wed, 20 Apr 2005 16:06:32 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) by pi.codefab.com (Postfix) with ESMTP id 20C735C84; Wed, 20 Apr 2005 16:06:31 -0400 (EDT) Message-ID: <4266B626.2000404@mac.com> Date: Wed, 20 Apr 2005 16:05:58 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <200504201837.40830.doconnor@gsoft.com.au> <20050420022128.B421@xorpc.icir.org> <20050420131744.t092cv40dck804ww@netchild.homeip.net> In-Reply-To: <20050420131744.t092cv40dck804ww@netchild.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 20:06:35 -0000 Alexander Leidinger wrote: > Luigi Rizzo wrote: [ ... ] > AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the > tree needs a firmware blob, ath needs a blob (but the license seems to be > ok, so we can have it in the tree), the newly added WLAN drivers need a > binary blob and some other pieces need a blob too. Having a general way of > adding the blob would be better than reinventing the wheel. Bruce Perens pointed me at an interface called request_firmware(), being adopted by Debian to deal with this issue: http://lwn.net/Articles/32997/ http://lwn.net/Articles/32671/ -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 20:12:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA46816A4CE for ; Wed, 20 Apr 2005 20:12:43 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6539F43D1D for ; Wed, 20 Apr 2005 20:12:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3KKA8Oc038838; Wed, 20 Apr 2005 14:10:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 20 Apr 2005 14:10:08 -0600 (MDT) Message-Id: <20050420.141008.39176773.imp@bsdimp.com> To: yb@bashibuzuk.net From: Warner Losh In-Reply-To: <20050420200351.GV76080@bashibuzuk.net> References: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> <20050420200351.GV76080@bashibuzuk.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: New wireless drivers committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 20:12:44 -0000 > If I may ask: is the firmware not 'autoloaded' on OpenBSD by the > driver itself ? If so, what's wrong with this approach ? Nothing, per se, is wrong with the approach. It is a matter of actually doing it. There may also be some problems with existing drivers that use their own ad-hoc methods at boot time before / is mounted being able to find their firmware if a naive conversion were done... Warner From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 20:22:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9989E16A4CE; Wed, 20 Apr 2005 20:22:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96C6843D1D; Wed, 20 Apr 2005 20:22:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3KKOqQW090159; Wed, 20 Apr 2005 14:24:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4266B95A.7000909@samsco.org> Date: Wed, 20 Apr 2005 14:19:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org References: <200504080220.57899.max@love2party.net> <42626B36.1090204@samsco.org> In-Reply-To: <42626B36.1090204@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: monthly@FreeBSD.org Subject: Last REMINDER! Call for FreeBSD status reports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 20:22:59 -0000 All, Last call for the quartly status report! If you still intent to submit one, please do so in the next 12 hours. Also, I'd like to remind everyone that submission are open to everyone, not just FreeBSD developers. We welcome all reports on projects and events in the FreeBSD community. Scott Scott Long wrote: > All, > > This is a reminder that status reports are due. We are going to extend > the deadline until the 20th to encourage people to submit a few more > reports. If you have any projects that you've been working on in the > past 3 months that are interesting and you would like to share, please > submit a report as soon as possible. The new web form from Julian makes > it incredibly easy to generate a submission without having to know a > thing about XML. The link for this is at: > > http://www.freebsd.org/cgi/monthly.cgi > > So, please submit your reports to monthly@freebsd.org by the 20th. > > Thanks, > > Scott Long, Max Laier, Tom Rhodes > > Max Laier wrote: > >> All, >> >> It's time again for some recapitulation of your FreeBSD activities of >> the last months. In order to not collided with the preparation of the >> 5.4 release we extended the cycle from bi-monthly to three months, so >> this one is open for anything that happend in 2005 until now. >> Submissions are due by April 15 to monthly@freebsd.org >> >> As always, reports about every FreeBSD related activity of the past >> months and coming weeks are welcome. In the past there was some focus >> on technical issues. In order to turn this into a more complete >> PR-vehicle, we highly encourage and welcome reports on non-technical >> matters as well. >> >> If you are yet unfamiliar with the status-reports, please take a look >> at the past reports: http://www.FreeBSD.org/news/status/ >> >> To support you in the process of fitting your report into the >> xml-template (available from: >> http://www.freebsd.org/news/status/report-sample.xml for those who >> still prefer a plain old text editor) Julian Elischer came up with the >> idea and prototype to have a web based form. Many thanks for that >> work. The cgi-script is being reviewed on freebsd-www now and will be >> linked to from http://www.freebsd.org/news/status/ shortly. >> >> The new features from last time (categories and task-list) will be >> available, again. As a reminder the available categories are listed >> bellow. Please feel free to suggest additional entries: >> >> proj - Projects (non-specific) >> docs - Documentation >> kern - Kernel >> arch - Architectures >> ports - Ports >> vendor - Vendor / 3rd party software >> misc - Miscellaneous >> >> Submissions are due on April 15. Thanks a lot, and we are hoping for >> a big turn-out. >> > From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 21:33:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF35516A4CE for ; Wed, 20 Apr 2005 21:33:32 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8490F43D4C for ; Wed, 20 Apr 2005 21:33:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CBCBD53715; Wed, 20 Apr 2005 14:33:31 -0700 (PDT) Date: Wed, 20 Apr 2005 14:33:31 -0700 From: Kris Kennaway To: jroberson@chesapeake.net, current@FreeBSD.org Message-ID: <20050420213331.GA11373@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: witness_destroy: lock (sleep mutex) vnode interlock is not initialized X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 21:33:32 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Running 6.0 on a SMP package machine with vfs.lookup_shared=1 and WITNESS, I hit this panic after a few hours. At boot time it hit the vm page queue mutex/vnode interlock LOR, and it also hit a 'acquiring duplicate lock of same type: "vnode interlock"' when mounting the first nullfs instance, which may be related. panic: witness_destroy: lock (sleep mutex) vnode interlock is not initialized cpuid = 0 KDB: enter: panic [thread pid 148 tid 100132 ] Stopped at kdb_enter+0x30: leave db> wh Tracing pid 148 tid 100132 td 0xc572d180 kdb_enter(c0700f44,0,c07054af,f5774c38,c572d180) at kdb_enter+0x30 panic(c07054af,c06dff2c,c0716859,c070abdc,c7f66440) at panic+0x13e witness_destroy(c7f66440,c0700183,360,c0700545,c06df73d,c7f66440,c0716859,c070abdc,0,0) at witness_destroy+0x5a mtx_destroy(c7f66440,c7f663a8,8,c7f663a8,f5774cb8) at mtx_destroy+0xf2 vdestroy(c7f663a8,0,c070aaaf,271,0) at vdestroy+0x192 vnlru_free(c,0,c070aaaf,293,3e8) at vnlru_free+0x188 vnlru_proc(0,f5774d38,c06fe130,30c,c572d180) at vnlru_proc+0xb1 fork_exit(c058b9ee,0,f5774d38) at fork_exit+0x116 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xf5774d6c, ebp = 0 --- db> --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZsqrWry0BWjoQKURAmITAKCrHDoqe6ATJRL8K6STgsuGBdRyywCgyOaw PJJ1bL4RGXtc7RgCCe2DEPo= =DvXN -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 21:43:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C8D516A4CE for ; Wed, 20 Apr 2005 21:43:01 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA7343D31 for ; Wed, 20 Apr 2005 21:43:01 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2D9E353090; Wed, 20 Apr 2005 14:43:00 -0700 (PDT) Date: Wed, 20 Apr 2005 14:43:00 -0700 From: Kris Kennaway To: othermark Message-ID: <20050420214259.GA46821@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: LOR/page fault panic vfs_mountroot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 21:43:01 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 01:04:08PM -0700, othermark wrote: > Current as of a few minutes ago. LOR/panic. Dual processor box. >=20 > kernel has vlan, ipfw, and dummynet enabled, but this doesn't > look like the problem. =20 >=20 > Curiously, booting single user and mounting root there doesn't=20 > panic, but it does panic if you try to 'exit' to multiuser. >=20 > [...] > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disable= d, > default to accept, logging disabled > ad0: 19092MB at ata0-master UDMA33 > acd0: CDROM at ata1-master UDMA33 > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad0s1a > lock order reversal > 1st 0xc0a2d740 vm page queue mutex (vm page queue mutex) > @ /usr/src/sys/kern/vfs_bio.c:1485 > 2nd 0xc25e4d6c vnode interlock (vnode interlock) > @ /usr/src/sys/kern/vfs_subr.c:1992 This has been reported a half-dozen times or so. > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 01 > fault virtual address =3D 0x4ac0c092 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc0703f88 > stack pointer =3D 0x28:0xe5092b78 > frame pointer =3D 0x28:0xe5092b78 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 73 (sysctl) > [thread pid 73 tid 100060 ] > Stopped at strlen+0x8: cmpb $0,0(%edx) > db> show alllocks > Process 73 (sysctl) thread 0xc23b2600 (100060) > exclusive sx sysctl lock r =3D 0 (0xc09d1c60) locked > @ /usr/src/sys/kern/kern_sysctl.c:1335 > exclusive sleep mutex Giant r =3D 0 (0xc09d1620) locked > @ /usr/src/sys/kern/kern_sysctl.c:1273 I think this one might be new. Please obtain a debugging traceback. Kris --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZszjWry0BWjoQKURAq2XAJ4k3OYEbV2m/5ptuKKGcnwAJMS+RQCeK/Bx CIKNCGTjosvqefmh+3c6Gu8= =AiZ/ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 21:49:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9888416A4CF for ; Wed, 20 Apr 2005 21:49:38 +0000 (GMT) Received: from email.aon.at (warsl404pip8.highway.telekom.at [195.3.96.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D1B443D31 for ; Wed, 20 Apr 2005 21:49:37 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 31184 invoked from network); 20 Apr 2005 21:49:34 -0000 Received: from m124p019.dipool.highway.telekom.at ([62.46.5.115]) (envelope-sender ) by smarthub75.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 20 Apr 2005 21:49:34 -0000 From: Stefan Ehmann To: Damien Bergamini In-Reply-To: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> References: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> Content-Type: text/plain Date: Wed, 20 Apr 2005 23:49:34 +0200 Message-Id: <1114033774.862.17.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: New wireless drivers committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 21:49:38 -0000 On Wed, 2005-04-20 at 21:08 +0200, Damien Bergamini wrote: > I've recently imported four new wireless drivers into the tree: > > ipw(4) - driver for Intel PRO/Wireless 2100 adapters (MiniPCI). > iwi(4) - driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG > adapters (PCI or MiniPCI). > ral(4) - driver for Ralink RT2500 wireless adapters (PCI or CardBus). > ural(4) - driver for Ralink RT2500USB wireless USB 2.0 adapters. > > ipw(4) and iwi(4) both require firmwares to operate. > These firmwares can't be redistributed with the base system due to > license restrictions. See firmware licensing terms here: > http://ipw2100.sourceforge.net/firmware.php?fid=4 > Ports which include the firmware images as well as the firmware loader > are being worked on. My 2200BG just works fine here with WEP (as before). Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 23:03:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE59E16A4CE for ; Wed, 20 Apr 2005 23:03:33 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 300C643D2F for ; Wed, 20 Apr 2005 23:03:33 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao02.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050420230330.WNMZ6521.lakermmtao02.cox.net@dolphin.local.net>; Wed, 20 Apr 2005 19:03:30 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3KN3N4B035749; Wed, 20 Apr 2005 18:03:27 -0500 (CDT) (envelope-from conrads@cox.net) Date: Wed, 20 Apr 2005 18:03:23 -0500 From: "Conrad J. Sabatier" To: Eric Anderson Message-ID: <20050420180323.6d2ef473@dolphin.local.net> In-Reply-To: <4265AA6D.5070406@centtech.com> References: <48D44BB27BDE3840BDF18E59CB169A5C83A02E@bcs-mail3.internal.cacheflow.com> <4265AA6D.5070406@centtech.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: "Li, Qing" cc: freebsd-current@freebsd.org Subject: Locale weirdness after latest upgrade (was Re: cannot log on as root after upgrade) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 23:03:33 -0000 On Tue, 19 Apr 2005 20:03:41 -0500, Eric Anderson wrote: > Li, Qing wrote: > > I performed a cvs sync today and buildworld. After the system > > reboot > > I cannot log on as root, the error message that is shown on > > console > > is "login: pam_acct_mgmt(): authentication error". > > I can still log on as a normal user. > > > > What do I need to do to fix this? Did I screw something up > > during mergemaster ? > > Sounds like it - can you boot into single user mode and check out your > passwd file? I suspect he may be encountering the same problem I'm seeing here after my latest upgrade today, namely, locale weirdness. If I set any locale-related environment variables (LANG, LC_ALL, or whatever) in my .bashrc, I can't login. Bash just core dumps immediately (even after rebuilding bash). I had the same problem with kdm. I had to change the LANG=en_US default setting in kdmrc to LANG=C. Setting it to null also produced the same behavior, by the way. I discovered the problem by running gdb on the core dumps I was getting from bash and kdm_greet. Here's the head of a backtrace from bash: #0 strcpy () at /usr/src/lib/libc/amd64/string/strcpy.S:52 #1 0x0000000800be2413 in __collate_load_tables ( encoding=0x800d41a80 "en_US.ISO8859-1") at /usr/src/lib/libc/locale/collate.c:86 #2 0x0000000800bb59d8 in loadlocale (category=1) at /usr/src/lib/libc/locale/setlocale.c:283 #3 0x0000000800bb5741 in setlocale (category=0, locale=0x5a2580 "en_US.ISO8859-1") at /usr/src/lib/libc/locale/setlocale.c:198 (the rest has no symbols) This is very strange. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 23:27:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFB7516A4CE for ; Wed, 20 Apr 2005 23:27:30 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FAD143D49 for ; Wed, 20 Apr 2005 23:27:30 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050420232728.VIML28448.lakermmtao09.cox.net@dolphin.local.net> for ; Wed, 20 Apr 2005 19:27:28 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3KNRTEn035972 for ; Wed, 20 Apr 2005 18:27:29 -0500 (CDT) (envelope-from conrads@cox.net) Date: Wed, 20 Apr 2005 18:27:29 -0500 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20050420182729.0314c999@dolphin.local.net> In-Reply-To: <20050420180323.6d2ef473@dolphin.local.net> References: <48D44BB27BDE3840BDF18E59CB169A5C83A02E@bcs-mail3.internal.cacheflow.com> <4265AA6D.5070406@centtech.com> <20050420180323.6d2ef473@dolphin.local.net> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Locale weirdness after latest upgrade (was Re: cannot log on as root after upgrade) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 23:27:31 -0000 On Wed, 20 Apr 2005 18:03:23 -0500, "Conrad J. Sabatier" wrote: > > I suspect he may be encountering the same problem I'm seeing here > after my latest upgrade today, namely, locale weirdness. > > If I set any locale-related environment variables (LANG, LC_ALL, or > whatever) in my .bashrc, I can't login. Bash just core dumps > immediately (even after rebuilding bash). I had the same problem with > kdm. I had to change the LANG=en_US default setting in kdmrc to > LANG=C. Setting it to null also produced the same behavior, by the > way. > > I discovered the problem by running gdb on the core dumps I was > getting from bash and kdm_greet. Here's the head of a backtrace from > bash: > > #0 strcpy () at /usr/src/lib/libc/amd64/string/strcpy.S:52 > #1 0x0000000800be2413 in __collate_load_tables ( > encoding=0x800d41a80 "en_US.ISO8859-1") > at /usr/src/lib/libc/locale/collate.c:86 > #2 0x0000000800bb59d8 in loadlocale (category=1) > at /usr/src/lib/libc/locale/setlocale.c:283 > #3 0x0000000800bb5741 in setlocale (category=0, > locale=0x5a2580 "en_US.ISO8859-1") > at /usr/src/lib/libc/locale/setlocale.c:198 > > (the rest has no symbols) > > This is very strange. Quick followup: using either C or POSIX locales will work OK. Null locale seems to be OK as well. Anything else bombs, though. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 00:40:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8F0416A4CE for ; Thu, 21 Apr 2005 00:40:45 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80C043D3F for ; Thu, 21 Apr 2005 00:40:44 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOPfu-0004jN-Px for freebsd-current@freebsd.org; Thu, 21 Apr 2005 02:36:10 +0200 Received: from gn-hgk-15cd4.adsl.wanadoo.nl ([81.69.122.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 02:36:10 +0200 Received: from A.S.Usov by gn-hgk-15cd4.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 02:36:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Alexander S. Usov" Date: Thu, 21 Apr 2005 02:40:24 +0200 Organization: KVI Lines: 24 Message-ID: References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> <20050418140117.GH2298@poupinou.org> <4263C6C5.300@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gn-hgk-15cd4.adsl.wanadoo.nl User-Agent: KNode/0.9.0 Sender: news Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 00:40:45 -0000 Eric Anderson wrote: > Ok, I've attached my tweaks to PHK's adaptive. I run it like this: > > /usr/sbin/powerd -a max -b adaptive2 -p 100 -r 20 > > Seems to do a pretty decent job at being responsive, yet gives me a longer > battery time than the default adaptive. Not perfect, but still better I > think.. This one works quite nicely, but you should add an additional check that your index "i" is not bigger that "numfreqs-1" when you are going to decrease a speed. But in general, it looks that a main problem with original adaptive algorithm is that it is possible to decrease an effective cpu frequency to an incredibly small values (for mine centrino it can go from 1.3Ghz down to 75Mhz), where even the easiest things take a lot of time, so it is forced to increase it. It looks that just limiting the minimal frequency by a something like 200-300 Mhz should make the original adaptive algorithm work much better. -- Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 02:08:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1942916A4CE for ; Thu, 21 Apr 2005 02:08:40 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED6C543D1D for ; Thu, 21 Apr 2005 02:08:39 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id E094072DDB; Wed, 20 Apr 2005 19:08:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id DBAEF72DD4; Wed, 20 Apr 2005 19:08:39 -0700 (PDT) Date: Wed, 20 Apr 2005 19:08:39 -0700 (PDT) From: Doug White To: Chuck Swiger In-Reply-To: <4266B626.2000404@mac.com> Message-ID: <20050420190715.A89198@carver.gumbysoft.com> References: <20050419225640.7B92816A4CF@hub.freebsd.org> <20050420104309.hqhvxfmu00cskwks@netchild.homeip.net> <20050420022128.B421@xorpc.icir.org><4266B626.2000404@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: freebsd-current@freebsd.org Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 02:08:40 -0000 On Wed, 20 Apr 2005, Chuck Swiger wrote: > Alexander Leidinger wrote: > > Luigi Rizzo wrote: > [ ... ] > > AFAIK we don't have such a facility. A disc controller (SCSI/RAID?) in the > > tree needs a firmware blob, ath needs a blob (but the license seems to be > > ok, so we can have it in the tree), the newly added WLAN drivers need a > > binary blob and some other pieces need a blob too. Having a general way of > > adding the blob would be better than reinventing the wheel. > > Bruce Perens pointed me at an interface called request_firmware(), being > adopted by Debian to deal with this issue: > > http://lwn.net/Articles/32997/ > http://lwn.net/Articles/32671/ And there's "load -t foo_type file" from loader. We use that for md images, compiled ACPI DSDTs, etc... -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 02:12:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F2CF16A4CE for ; Thu, 21 Apr 2005 02:12:05 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EF0243D2F for ; Thu, 21 Apr 2005 02:12:05 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5206B72DDB; Wed, 20 Apr 2005 19:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4DCD072DD4; Wed, 20 Apr 2005 19:12:05 -0700 (PDT) Date: Wed, 20 Apr 2005 19:12:05 -0700 (PDT) From: Doug White To: marek gartrend In-Reply-To: <20050419224935.G30305@area51.capnet.state.tx.us> Message-ID: <20050420191004.N89198@carver.gumbysoft.com> References: <20050419224935.G30305@area51.capnet.state.tx.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.4 RC3 failure on Gateway ALR 7200R. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 02:12:05 -0000 On Tue, 19 Apr 2005, marek gartrend wrote: > I tried to load 5.4-RC3 (please redirect me to the correct list > if this isn't the one) on a Gateway ALR 7200R, dual processor > 400MHz Pentium II. > > The normal boot from the CD would not boot, stopping at the > agp0: line. > > I booted to safe mode and installed from there. When I boot > it stops at: > > agp0: at device 1.0 on pci0 > > in safe bood mode, the next line is: > > pcib1: at device 1.0 on pci0 > > If I boot with extra logging, it ends with: > > agp0: at device 1.0 on pci0 > agp0: Lazy allocation of 0x4000000 bytes rid 0x10 type 3 at 0 > agp0: allocating GATT for aperture size of 64M > [nothing more] > > I tried setting ACPI off (cause it was the only thing I know how to > do) with: > > hint.acpi.0.disabled="1" > > in loader.conf (I also tried putting it in device.hints) but that made > no difference. Is this machine a no-go? This is untested, but try this to disable the agp device at the loader prompt: set hint.agp.0.disabled="1" Worst case you could boot with safe mode again and rebuild a kenrel without the agp device. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 02:39:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1959916A4CE for ; Thu, 21 Apr 2005 02:39:07 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDB9443D46 for ; Thu, 21 Apr 2005 02:39:06 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DORas-000FBf-Km for freebsd-current@freebsd.org; Thu, 21 Apr 2005 02:39:06 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DORam-0000I6-Gb for freebsd-current@freebsd.org; Wed, 20 Apr 2005 16:39:00 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16999.4675.875509.763846@roam.psg.com> Date: Wed, 20 Apr 2005 16:38:59 -1000 To: FreeBSD Current Subject: sandisk usb freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 02:39:07 -0000 running current as of yesterday on a thinkpd t41 picked up a sandisk cruzer 128mb usb disk stick. it looks ok from winxp plug it in, the stick's led lights up syslog sez umass0: SanDisk Corporation Cruzer Mini, rev 2.00/1.04, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) fdisk da0 either locks up or causes reboot with no disk flowers savecore: no dumps found any pointers on how to best debug? randy From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 03:02:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B24F16A4CE; Thu, 21 Apr 2005 03:02:42 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A30143D49; Thu, 21 Apr 2005 03:02:40 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp21AD.dyn.pacific.net.au (ppp21AD.dyn.pacific.net.au [61.8.33.173])j3L32a9B014136; Thu, 21 Apr 2005 13:02:37 +1000 From: Sam Lawrance To: freebsd-current@freebsd.org Content-Type: text/plain Date: Thu, 21 Apr 2005 13:02:53 +1000 Message-Id: <1114052573.1075.10.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: davidxu@freebsd.org Subject: kern/78474 for 5.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 03:02:42 -0000 Will this problem: Swapped out procs not brought in immediately after child exits http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 be dealt with for the release of 5.4? Perhaps I'm the only FreeBSD user with swapped out processes ;-) -Sam From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 05:21:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E741016A4CE for ; Thu, 21 Apr 2005 05:21:32 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA7D643D31 for ; Thu, 21 Apr 2005 05:21:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3L5LN4t089675; Thu, 21 Apr 2005 14:51:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 21 Apr 2005 14:51:15 +0930 User-Agent: KMail/1.8 References: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> In-Reply-To: <000b01c545dc$5dbf0a90$0300a8c0@COMETE> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <200504211451.15494.doconnor@gsoft.com.au> X-Spam-Score: -1.5 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Damien Bergamini Subject: Re: New wireless drivers committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 05:21:33 -0000 On Thu, 21 Apr 2005 04:38, Damien Bergamini wrote: > ipw(4) and iwi(4) both require firmwares to operate. > These firmwares can't be redistributed with the base system due to > license restrictions. See firmware licensing terms here: > http://ipw2100.sourceforge.net/firmware.php?fid=4 > Ports which include the firmware images as well as the firmware loader > are being worked on. It seems you have to bring the interface up before SSID scanning happens, eg.. [inchoate 11:25] ~ >sudo kldload if_ipw SSH passphrase: [inchoate 11:25] ~ >sudo ipwcontrol -i ipw0 -f /usr/local/libdata/if_ipw/ipw2100-1.3.fw [inchoate 11:30] ~ >/usr/bin/time sudo ifconfig ipw0 scan 0.06 real 0.02 user 0.01 sys [inchoate 11:30] ~ >sudo ifconfig ipw0 ssid x up 1.2.3.4 [inchoate 14:45] ~ >/usr//bin/time sudo ifconfig ipw0 scan SSID BSSID CHAN RATE S:N INT CAPS 00:00:00:00:00:00 9 0M 0:0 0 0... 00:07:85:92:bf:10 9 11M 10:0 100 ES WME AP0CAE6B 00:03:2f:0c:ae:6b 6 22M 10:0 100 EB 0.11 real 0.01 user 0.00 sys Also I expect the first entry in that list is a little bogus :) -- 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 From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 06:38:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71FFB16A4CE for ; Thu, 21 Apr 2005 06:38:58 +0000 (GMT) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F3843D3F for ; Thu, 21 Apr 2005 06:38:57 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: from tyrael.linnet (p54BCD478.dip.t-dialin.net [84.188.212.120]) (authenticated bits=0) (8.12.10/8.12.9/INF-2.0-MA-SOLARIS-2.8) with ESMTP id j3L6ctGR023885 for ; Thu, 21 Apr 2005 08:38:55 +0200 (MEST) Date: Thu, 21 Apr 2005 08:38:30 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20050421083830.726cf741.sebastian.ssmoller@gmx.net> In-Reply-To: References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> <20050418140117.GH2298@poupinou.org> <4263C6C5.300@centtech.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 06:38:58 -0000 > > But in general, it looks that a main problem with original adaptive > algorithm is that it is possible to decrease an effective cpu > frequency to an incredibly small values (for mine centrino it can go > from 1.3Ghz down to 75Mhz), where even the easiest things take a lot > of time, so it is forced to increase it. It looks that just limiting > the minimal frequency by a something like 200-300 Mhz should make the > original adaptive algorithm work much better. > agree! estctrl decreased speed only down to 600MHz which worked perfectly for me ... guess even 200MHz would be a bit to slow still .. seb -- "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939 From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 06:54:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C41516A4CE for ; Thu, 21 Apr 2005 06:54:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E54943D2F; Thu, 21 Apr 2005 06:54:46 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3L6siLP048435; Thu, 21 Apr 2005 06:54:45 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42674E61.9050005@freebsd.org> Date: Thu, 21 Apr 2005 14:55:29 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Lawrance References: <1114052573.1075.10.camel@dirk.no.domain> In-Reply-To: <1114052573.1075.10.camel@dirk.no.domain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: kern/78474 for 5.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 06:54:46 -0000 Sam Lawrance wrote: >Will this problem: > >Swapped out procs not brought in immediately after child exits >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > >be dealt with for the release of 5.4? > >Perhaps I'm the only FreeBSD user with swapped out processes ;-) > >-Sam > > > I don't know why people keep sending mail to me about the problem, I received another mail said that -CURRENT still has the problem, I will look those code, I thought someone ( I can not remember) had already fixed it in kern_exit.c. ;-) David Xu From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 07:33:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38A5316A4CE for ; Thu, 21 Apr 2005 07:33:54 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id B14D943D1F for ; Thu, 21 Apr 2005 07:33:53 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id C5CD5C0CF; Thu, 21 Apr 2005 09:33:51 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 5C3C0405A; Thu, 21 Apr 2005 09:33:09 +0200 (CEST) Date: Thu, 21 Apr 2005 09:33:09 +0200 From: Jeremie Le Hen To: "Li, Qing" Message-ID: <20050421073309.GL91329@obiwan.tataz.chchile.org> References: <4265AA6D.5070406@centtech.com> <48D44BB27BDE3840BDF18E59CB169A5C592378@bcs-mail3.internal.cacheflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48D44BB27BDE3840BDF18E59CB169A5C592378@bcs-mail3.internal.cacheflow.com> User-Agent: Mutt/1.5.9i cc: freebsd-current@freebsd.org cc: Eric Anderson Subject: Re: cannot log on as root after upgrade X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 07:33:54 -0000 > Yes, I booted into single user and changed password. > However, run into the same problem after the reboot. I can actually successfully login as root but when I try to boot an older kernel (I can't remember how old it is, maybe one month old), I have the same problem. My current world is in sync with my kernel. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 08:36:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E25B16A4CE; Thu, 21 Apr 2005 08:36:20 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE3CC43D1D; Thu, 21 Apr 2005 08:36:19 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFA00AHDFN1ML50@bgo1smout1.broadpark.no>; Thu, 21 Apr 2005 10:30:37 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFA003GJFYDAUA0@bgo1sminn1.broadpark.no>; Thu, 21 Apr 2005 10:37:25 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 64860EBD28; Thu, 21 Apr 2005 10:36:18 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id C9987EBCB4; Thu, 21 Apr 2005 10:36:12 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id C40B733C1C; Thu, 21 Apr 2005 10:36:12 +0200 (CEST) Date: Thu, 21 Apr 2005 10:36:12 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050420153528.GC77731@stack.nl> To: Marc Olzheim Message-id: <86zmvssf0j.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-current@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 08:36:20 -0000 Marc Olzheim writes: > Ah, I was reading the SUSv2 page: > > http://www.opengroup.org/onlinepubs/009695399/functions/write.html > > instead of the POSIX version. POSIX =3D=3D SUSv3 these days. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 09:03:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3669716A4CF for ; Thu, 21 Apr 2005 09:03:02 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A2A43D1D for ; Thu, 21 Apr 2005 09:02:59 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOXTw-0002Kk-SE for freebsd-current@freebsd.org; Thu, 21 Apr 2005 10:56:20 +0200 Received: from kvip88.kvi.nl ([129.125.15.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 10:56:20 +0200 Received: from A.S.Usov by kvip88.kvi.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 10:56:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Alexander S. Usov" Date: Thu, 21 Apr 2005 10:59:49 +0200 Organization: KVI Lines: 25 Message-ID: References: <4263A33A.3030201@centtech.com> <2304.1113826754@critter.freebsd.dk> <20050418140117.GH2298@poupinou.org> <4263C6C5.300@centtech.com> <20050421083830.726cf741.sebastian.ssmoller@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kvip88.kvi.nl User-Agent: KNode/0.9.0 Sender: news Subject: Re: powerd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 09:03:02 -0000 sebastian ssmoller wrote: >> >> But in general, it looks that a main problem with original adaptive >> algorithm is that it is possible to decrease an effective cpu >> frequency to an incredibly small values (for mine centrino it can go >> from 1.3Ghz down to 75Mhz), where even the easiest things take a lot >> of time, so it is forced to increase it. It looks that just limiting >> the minimal frequency by a something like 200-300 Mhz should make the >> original adaptive algorithm work much better. >> > > agree! estctrl decreased speed only down to 600MHz which worked > perfectly for me ... guess even 200MHz would be a bit to slow still .. It really depends. I left my notebook running for a whole night and most of the time it was fluctuating at frequencies of about 75-300 Mhz, which is more than enough for mldonkey to work. But for interactive work one would really prefer to have it higher. -- Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 10:07:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64AB616A4CE; Thu, 21 Apr 2005 10:07:29 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4BE643D62; Thu, 21 Apr 2005 10:07:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3LA7SH5057839; Thu, 21 Apr 2005 06:07:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3LA7Si1076161; Thu, 21 Apr 2005 06:07:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D316B7306E; Thu, 21 Apr 2005 06:07:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050421100727.D316B7306E@freebsd-current.sentex.ca> Date: Thu, 21 Apr 2005 06:07:27 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 10:07:29 -0000 TB --- 2005-04-21 08:28:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-21 08:28:03 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-21 08:28:03 - checking out the source tree TB --- 2005-04-21 08:28:03 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-21 08:28:03 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-21 08:34:45 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-21 08:34:45 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-21 08:34:45 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-04-21 09:47:18 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-21 09:47:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-21 09:47:18 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 21 09:47:18 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Apr 21 10:03:08 UTC 2005 TB --- 2005-04-21 10:03:08 - generating LINT kernel config TB --- 2005-04-21 10:03:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-21 10:03:08 - /usr/bin/make -B LINT TB --- 2005-04-21 10:03:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-21 10:03:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-21 10:03:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 21 10:03:08 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:45: /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:43: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-21 10:07:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-21 10:07:27 - ERROR: failed to build lint kernel TB --- 2005-04-21 10:07:27 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 10:22:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0596B16A4CE; Thu, 21 Apr 2005 10:22:21 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B7DC43D41; Thu, 21 Apr 2005 10:22:19 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DOYp7-000MI5-CA; Thu, 21 Apr 2005 13:22:17 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Danny Braniss In-Reply-To: Message from Danny Braniss Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Apr 2005 13:22:17 +0300 From: Danny Braniss Message-ID: cc: current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: panic: userret: Returning with 1 locks held. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 10:22:21 -0000 (moving this to current, since it's not amd64 specific). the followin is caused if unionfs is loaded, compiled into the kernel works ok (current 6.0): > with the latest kernel, the message changed somewhat, but the panic is > still there (this is an amd64): > > trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xffffffff8038e3f5 > stack pointer = 0x10:0xffffffffb280e7b0 > frame pointer = 0x10:0xffffffffb280e7e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 241 (sh) > [thread pid 241 tid 100071 ] > Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) > db> tr > Tracing pid 241 tid 100071 td 0xffffff007ae25980 > _mtx_lock_flags() at _mtx_lock_flags+0x35 > exec_map_first_page() at exec_map_first_page+0x60 > kern_execve() at kern_execve+0x2a0 > execve() at execve+0x5d > syscall() at syscall+0x4ab > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = > 0x7fffffffcbf8, rbp = 0 --- > db> show lockedvnods > Locked vnodes > > 0xffffff0061a48000: tag union, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_TEXT) > lock type union: EXCL (count 1) by thread 0xffffff007ae25980 (pid 241) > vp=0xffffff0061a48000, uppervp=0, lowervp=0xffffff00626187e0 > union: lower > 0xffffff00626187e0: tag nfs, type VREG > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags () > v_object 0xffffff007c3a87e0 ref 0 pages 1 > > fileid 47269 fsid 0x900ff01 > db> tr 241 > Tracing pid 241 tid 100071 td 0xffffff007ae25980 > _mtx_lock_flags() at _mtx_lock_flags+0x35 > exec_map_first_page() at exec_map_first_page+0x60 > kern_execve() at kern_execve+0x2a0 > execve() at execve+0x5d > syscall() at syscall+0x4ab > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = > 0x7fffffffcbf8, rbp = 0 --- > db> > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 11:25:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FFA816A4CE for ; Thu, 21 Apr 2005 11:25:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FFB643D53; Thu, 21 Apr 2005 11:25:52 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3LBPnPa083711; Thu, 21 Apr 2005 11:25:51 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42678DC4.40309@freebsd.org> Date: Thu, 21 Apr 2005 19:25:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Lawrance References: <1114052573.1075.10.camel@dirk.no.domain> In-Reply-To: <1114052573.1075.10.camel@dirk.no.domain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: kern/78474 for 5.4? (kernel stack swapout problem again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 11:25:52 -0000 Sam Lawrance wrote: >Will this problem: > >Swapped out procs not brought in immediately after child exits >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > >be dealt with for the release of 5.4? > >Perhaps I'm the only FreeBSD user with swapped out processes ;-) > >-Sam > > > > I have noticed that current spinlock implementation no longer means that CPU must be in critical region (critical_enter is called), even previous hack TDP_WAKEPROC0 is no longer correct, :(, I think it is the time to disable swapout. David Xu From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 13:40:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B064616A4CF for ; Wed, 20 Apr 2005 13:40:54 +0000 (GMT) Received: from mail54.messagelabs.com (mail54.messagelabs.com [216.82.244.35]) by mx1.FreeBSD.org (Postfix) with SMTP id F1C7343D39 for ; Wed, 20 Apr 2005 13:40:53 +0000 (GMT) (envelope-from dchance@e-ins.net) X-VirusChecked: Checked X-Env-Sender: dchance@e-ins.net X-Msg-Ref: server-14.tower-54.messagelabs.com!1114004452!42562824!1 X-StarScan-Version: 5.4.11; banners=e-ins.net,-,- X-Originating-IP: [216.143.138.195] Received: (qmail 17687 invoked from network); 20 Apr 2005 13:40:52 -0000 Received: from unknown (HELO mail1.e-ins.net) (216.143.138.195) by server-14.tower-54.messagelabs.com with SMTP; 20 Apr 2005 13:40:52 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 20 Apr 2005 09:44:09 -0400 Message-ID: <83DCBBE0520E0947A4B7E16F6FD209B945630D@mail1.e-ins.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New driver loading scheme for Project Evil, need input Thread-Index: AcVFM5OGEmQ+a8S4QU2zkmq/MJLwpgAetN5A From: "Daryl Chance" To: "Bill Paul" , X-Mailman-Approved-At: Thu, 21 Apr 2005 11:43:30 +0000 Subject: RE: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 13:40:54 -0000 >=20The=20end=20result=20is=20that=20installing=20a=20Windows=20driver=20s= hould=20be=20as=20simple >=20as: >=20 >=20-=20run=20the=20script >=20-=20give=20it=20your=20foo.inf=20and=20foo.sys=20files=20when=20it=20a= sks=20you >=20-=20it=20spits=20out=20a=20foo_sys.ko=20module=20and=20you=20kldload=20= it >=20-=20the=20end What=20if=20you=20did=20something=20like=20portinstall=20does,=20and=20lis= t=20all=20the=20paths that=20the=20.inf=20and=20.sys=20coexists=20and=20have=20you=20answer=20no= =20or=20yes=20to=20that path? root@ns1#=20portinstall=20jakarta-tomcat --->=20=20Found=204=20ports=20matching=20'jakarta-tomcat': =20=20=20=20=20=20=20=20www/jakarta-tomcat3 =20=20=20=20=20=20=20=20www/jakarta-tomcat4 =20=20=20=20=20=20=20=20www/jakarta-tomcat41 =20=20=20=20=20=20=20=20www/jakarta-tomcat5 Install=20'www/jakarta-tomcat3'?=20[yes] Thoughts?=20=20I'm=20not=20sure=20if=20it=20would=20be=20easier=20to=20wri= te=20the=20code=20to search=20the=20disk,=20or=20write=20the=20code=20to=20take=20the=20input=20= and=20check=20to=20make sure=20the=20path=20exists=20and=20error=20out=20if=20it=20doesn't,=20etc=20= etc=20:). Daryl _____________________________________________________________ This=20email=20has=20been=20scanned=20by=20MessageLabs=20on=20behalf=20of=20= E-INS From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 15:09:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A61816A4CE for ; Wed, 20 Apr 2005 15:09:54 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E509943D41 for ; Wed, 20 Apr 2005 15:09:53 +0000 (GMT) (envelope-from rexroof@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so160454wri for ; Wed, 20 Apr 2005 08:09:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V4F2/bx7CiJfXn6FgV/DL/q3TeHLkR1OPijq+uclZU5qq65d4S6+1hMP4eyVKKhprbMmms9yWV9gqrH5tqOjDAcN2MHx+V+yZ+r49vBRgrgbqh1i3n5EUvZAeKLAeni6cRalUP2PJxxBsXnFa+PjTiMmHPpTemMHPtUaBecn8GA= Received: by 10.54.3.66 with SMTP id 66mr422500wrc; Wed, 20 Apr 2005 08:09:50 -0700 (PDT) Received: by 10.54.62.14 with HTTP; Wed, 20 Apr 2005 08:09:50 -0700 (PDT) Message-ID: <6afb69aa05042008093d6d59d0@mail.gmail.com> Date: Wed, 20 Apr 2005 11:09:50 -0400 From: Rex Roof To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <6afb69aa05042008065db9d0cb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6afb69aa05042008065db9d0cb@mail.gmail.com> X-Mailman-Approved-At: Thu, 21 Apr 2005 11:43:30 +0000 Subject: gvinum during bootup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rex Roof List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 15:09:54 -0000 I'm running a FreeBSD6 machine current as of a few days ago and I'm working on a gvinum configuration, I couldn't find any place where it referenced gvinum on startup so after fussing around with the rc system a little, I wrote an /etc/rc.d/gvinum script that looks like so: #!/bin/sh # PROVIDE: disks # KEYWORD: nojail . /etc/rc.subr name=3D"gvinum" start_cmd=3D"gvinum_start" stop_cmd=3D":" gvinum_start() { case ${gvinum_enable} in [Yy][Ee][Ss]) echo "starting gvinum." /sbin/gvinum start ;; esac } load_rc_config $name run_rc_command "$1" # END I then added gvinum_enable=3D"YES" to my /etc/rc.conf and it seems to be working great. rcorder tells me this is run a few steps before ccd, which is confusing because I used the same keywords and ccd isn't requested anywhere. is there some place this can be added to -current? I'm assuming the change from vinum to gvinum is still in some sort of transition. From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 17:16:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1FCC16A4CE; Wed, 20 Apr 2005 17:16:08 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84F5F43D31; Wed, 20 Apr 2005 17:16:08 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j3KHG6Ni036897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 20 Apr 2005 13:16:06 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j3KHG5C4036894; Wed, 20 Apr 2005 13:16:05 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16998.36437.809896.936800@khavrinen.csail.mit.edu> Date: Wed, 20 Apr 2005 13:16:05 -0400 To: Marc Olzheim In-Reply-To: <20050420143842.GB77731@stack.nl> References: <20050418202213.GC1157@green.homeunix.org> <20050418203321.GA88774@stack.nl> <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 20 Apr 2005 13:16:06 -0400 (EDT) X-Virus-Scanned: ClamAV 0.83/842/Tue Apr 19 17:39:01 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Thu, 21 Apr 2005 11:43:30 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:16:09 -0000 < said: > Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short > writes on regular files... ? I believe it is the intent of the Standard to prohibit this (a paragraph in the rationale says that short writes can only happen if O_NONBLOCK is set, but this is clearly wrong because the normative text says end-of-medium also results in a short write) but there does not appear to be any language which requires atomic behavior for descriptors other than pipes and FIFOs. As a quality-of-implementation matter, for writes to regular files not to be atomic would be considered surprising. -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 17:29:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73AF716A4CE; Wed, 20 Apr 2005 17:29:12 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E5743D49; Wed, 20 Apr 2005 17:29:12 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j3KHTANG037030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 20 Apr 2005 13:29:11 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j3KHTAmT037027; Wed, 20 Apr 2005 13:29:10 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16998.37222.529748.205885@khavrinen.csail.mit.edu> Date: Wed, 20 Apr 2005 13:29:10 -0400 To: Brian Fundakowski Feldman In-Reply-To: <20050420155233.GJ1157@green.homeunix.org> References: <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 20 Apr 2005 13:29:11 -0400 (EDT) X-Virus-Scanned: ClamAV 0.83/842/Tue Apr 19 17:39:01 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Thu, 21 Apr 2005 11:43:30 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 17:29:12 -0000 < said: > I think the first is more useful behavior than the last. Supporting it > should be exactly the same as supporting what happens if the actual > filesystem fills up. In this case, the filesystem is being requested to > write more "than there is room for." Returning a short write for operations on regular files would definitely be considered astonishing. The changes that you have made should be considered flow control, not admission control, and should appear to the user no differently than if we were waiting for a slow disk to write something; i.e., the user thread should be blocked until either the entire write completes, or the process is interrupted by a signal. -GAWollman From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 22:19:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA4416A4CE for ; Wed, 20 Apr 2005 22:19:07 +0000 (GMT) Received: from e.0x20.net (gw.0x20.net [217.69.68.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66D243D39 for ; Wed, 20 Apr 2005 22:19:06 +0000 (GMT) (envelope-from lars@0x20.net) Received: from bart.bsd-geek.de ([IPv6:2001:6f8:1336:0:20a:e4ff:fe24:403d]) (authenticated bits=128) by e.0x20.net (8.13.3/8.13.1/Submit) with ESMTP id j3KMJ4BN065614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Apr 2005 00:19:05 +0200 (CEST) (envelope-from lars@bsd-geek.de) Received: from bart.bsd-geek.de (localhost.bsd-geek.de [127.0.0.1]) by bart.bsd-geek.de (8.13.3/8.13.1) with ESMTP id j3KMJ3N2000984 for ; Thu, 21 Apr 2005 00:19:04 +0200 (CEST) (envelope-from lars@bart.bsd-geek.de) Received: (from lars@localhost) by bart.bsd-geek.de (8.13.3/8.13.1/Submit) id j3KMJ3iU000983 for current@freebsd.org; Thu, 21 Apr 2005 00:19:03 +0200 (CEST) (envelope-from lars) Date: Thu, 21 Apr 2005 00:19:03 +0200 From: Lars Engels To: current@freebsd.org Message-ID: <20050420221903.GA738@bart.bsd-geek.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 21 Apr 2005 11:43:30 +0000 Subject: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2005 22:19:08 -0000 Hi all! I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. Compilation and installation went fine, but when I try to start firefox, gkrellm and even portupgrade I get the following error message: /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol "i386_get_gsbase" Is there something i have not spotted in UPDATING? System: FreeBSD 6.0-CURRENT #5: Wed Apr 20 23:21:11 CEST 2005 TIA, Lars From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 11:45:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEE7B16A4CF; Thu, 21 Apr 2005 11:45:14 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F3543D3F; Thu, 21 Apr 2005 11:45:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3LBjDbC065103; Thu, 21 Apr 2005 07:45:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3LBjD6i005928; Thu, 21 Apr 2005 07:45:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 435417306E; Thu, 21 Apr 2005 07:45:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050421114513.435417306E@freebsd-current.sentex.ca> Date: Thu, 21 Apr 2005 07:45:13 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 11:45:15 -0000 TB --- 2005-04-21 10:07:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-21 10:07:28 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-21 10:07:28 - checking out the source tree TB --- 2005-04-21 10:07:28 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-21 10:07:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-21 10:14:08 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-21 10:14:08 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-21 10:14:08 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-21 11:22:03 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-21 11:22:03 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-21 11:22:03 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Apr 21 11:22:03 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Thu Apr 21 11:39:49 UTC 2005 TB --- 2005-04-21 11:39:49 - generating LINT kernel config TB --- 2005-04-21 11:39:49 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-21 11:39:49 - /usr/bin/make -B LINT TB --- 2005-04-21 11:39:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-21 11:39:49 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-21 11:39:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 21 11:39:49 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:51: /tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:50: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-21 11:45:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-21 11:45:13 - ERROR: failed to build lint kernel TB --- 2005-04-21 11:45:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 12:52:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5276516A4CE for ; Thu, 21 Apr 2005 12:52:40 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E57343D1D for ; Thu, 21 Apr 2005 12:52:39 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFA00D0CRSFSB@nemesis.sorbs.net> for freebsd-current@freebsd.org; Thu, 21 Apr 2005 22:53:05 +1000 (EST) Date: Thu, 21 Apr 2005 22:51:27 +1000 From: Matthew Sullivan To: freebsd-current@freebsd.org Message-id: <4267A1CF.3080903@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms090105020002080209020209; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 Subject: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 12:52:40 -0000 This is a cryptographically signed message in MIME format. --------------ms090105020002080209020209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hey all, I've been reading about problems with HP/Compaq's regarding launching of second CPUs on SMP systems. I've been through the BIOS settings and there seems to be no settings to change the APCI table etc.... Now one thing that does seem common, when I have BIOS's with MP table version set to 1.4 FreeBSD doesn't report the second CPU being launched (even though it is seen in the acpidump).... When I set the BIOS to version 1.2 of the MP table the second CPU is reported and launched. Now the Compaq DL380's I have done seem to have the ability to set 1.4 or 1.2 of the table ... mptable reports 1.4... (below) Any suggestions on how to launch the second CPU...? (kernel is 5.3-RELEASE-p9 with 'options SMP') kern.threads.virtual_cpu: 1 kern.smp.maxcpus: 16 kern.smp.cpus: 1 hw.ncpu: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 mptable: =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4ff0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x00 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f27c3 signature: 'PCMP' base table length: 412 version: 1.4 checksum: 0x1c OEM ID: 'COMPAQ ' Product ID: 'PROLIANT ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 43 local APIC address: 0xfee00000 extended table length: 184 extended table checksum: 13 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x10 BSP, usable 6 2 1 0x0381 0 0x10 AP, usable 6 8 6 0x383fbff -- Bus: Bus ID Type 0 PCI 1 PCI 9 ISA -- I/O APICs: APIC ID Version State Address 8 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT active-lo level 0 5:A 8 21 INT active-lo level 0 5:B 8 20 INT active-lo level 0 5:C 8 21 INT active-lo level 0 5:D 8 20 INT active-lo level 1 4:A 8 27 INT active-lo level 1 4:B 8 26 INT active-lo level 1 4:C 8 27 INT active-lo level 1 4:D 8 26 INT active-lo level 1 5:A 8 29 INT active-lo level 1 5:B 8 28 INT active-lo level 1 5:C 8 29 INT active-lo level 1 5:D 8 28 INT active-lo level 1 6:A 8 31 INT active-lo level 1 6:B 8 30 INT active-lo level 1 6:C 8 31 INT active-lo level 1 6:D 8 30 INT active-lo level 0 1:A 8 19 INT active-lo level 0 1:B 8 18 INT active-lo level 0 2:A 8 17 INT active-hi edge 9 1 8 1 INT active-hi edge 9 0 8 2 INT active-hi edge 9 3 8 3 INT active-hi edge 9 4 8 4 INT active-hi edge 9 5 8 5 INT active-hi edge 9 6 8 6 INT active-hi edge 9 7 8 7 INT active-hi edge 9 8 8 8 INT active-hi edge 9 9 8 9 INT active-hi edge 9 10 8 10 INT active-hi edge 9 11 8 11 INT active-hi edge 9 12 8 12 INT active-lo level 9 13 8 13 INT active-hi edge 9 14 8 14 INT active-hi edge 9 15 8 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 9 0 255 0 NMI conforms conforms 9 0 255 1 -- MPTABLE OUT OF ORDER! I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 9 0 8 0 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- System Address Space bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 -- System Address Space bus ID: 0 address type: I/O address address base: 0x0 address range: 0x0 -- System Address Space bus ID: 0 address type: memory address address base: 0xc3d00000 address range: 0x3300000 -- System Address Space bus ID: 0 address type: memory address address base: 0x40000000 address range: 0x83000000 -- System Address Space bus ID: 3 address type: I/O address address base: 0x0 address range: 0x0 -- System Address Space bus ID: 3 address type: memory address address base: 0x0 address range: 0x0 -- System Address Space bus ID: 3 address type: memory address address base: 0x0 address range: 0x0 -- System Address Space bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x60000 -- Bus Heirarchy bus ID: 9 bus info: 0x01 parent bus ID: 0 -- Compatibility Bus Address bus ID: 0 address modifier: add predefined range: 0x00000000 -- Compatibility Bus Address bus ID: 3 address modifier: subtract predefined range: 0x00000000 =============================================================================== apcidump -t /* RSD PTR: OEM=COMPAQ, ACPI_Rev=1.0x (0) RSDT=0x3fffc000, cksum=34 */ /* RSDT: Length=52, Revision=1, Checksum=132, OEMID=COMPAQ, OEM Table ID=RACEBAIT, OEM Revision=0x2, Creator ID=Ò, Creator Revision=0x162e Entries={ 0x3fffc040, 0x3fffc100, 0x3ffff800, 0x3fffc180 } */ /* FACP: Length=116, Revision=1, Checksum=190, OEMID=COMPAQ, OEM Table ID=MICRO, OEM Revision=0x2, Creator ID=Ò, Creator Revision=0x162e FACS=0x3fffc0c0, DSDT=0x3fffc200 INT_MODEL=APIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0x230, ACPI_ENABLE=0x1, ACPI_DISABLE=0x0, S4BIOS_REQ=0x0 PSTATE_CNT=0x0 PM1a_EVT_BLK=0x220-0x223 PM1a_CNT_BLK=0x230-0x231 PM_TMR_BLK=0x240-0x243 P_LVL2_LAT=65535 us, P_LVL3_LAT=65535 us FLUSH_SIZE=0, FLUSH_STRIDE=0 DUTY_OFFSET=0, DUTY_WIDTH=0 DAY_ALRM=0, MON_ALRM=0, CENTURY=0 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,SLP_BUTTON,FIX_RTC} */ /* FACS: Length=64, HwSig=0x0000abcd, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=12051, Revision=1, Checksum=225, OEMID=COMPAQ, OEM Table ID=DSDT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000b */ /* APIC: Length=78, Revision=1, Checksum=118, OEMID=COMPAQ, OEM Table ID=00000083, OEM Revision=0x2, Creator ID=, Creator Revision=0x0 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=0 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=1 Type=IO APIC APIC ID=8 INT BASE=0 ADDR=0x00000000fec00000 Type=Local NMI ACPI CPU=ALL LINT Pin=1 Flags={Polarity=conforming, Trigger=conforming} */ /* SSDT: Length=620, Revision=1, Checksum=60, OEMID=COMPAQ, OEM Table ID=SSDT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000b */ /* SPCR: Length=80, Revision=1, Checksum=14, OEMID=COMPAQ, OEM Table ID=SPCR_ROM, OEM Revision=0x1, Creator ID=Ò, Creator Revision=0x162e */ Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms090105020002080209020209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMTEyNTEyN1owIwYJKoZIhvcNAQkEMRYEFHuzuI4kbV1NjN3/ h5XgTL6pXpPDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQIfLi1cEVsI29wCx9OSQ76knPQg2g22RcHvDKmHdr0pSgeOhXBWbjXp/fNz67zOEBGrM mU46c1dcSyN0yWg0CIsAAAAAAAA= --------------ms090105020002080209020209-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 13:10:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5098D16A4CF for ; Thu, 21 Apr 2005 13:10:34 +0000 (GMT) Received: from seven.Alameda.net (seven.alameda.net [64.81.53.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 137FB43D49 for ; Thu, 21 Apr 2005 13:10:34 +0000 (GMT) (envelope-from ulf@Alameda.net) Received: by seven.Alameda.net (Postfix, from userid 1000) id BCD093A201; Thu, 21 Apr 2005 06:10:33 -0700 (PDT) Date: Thu, 21 Apr 2005 06:10:33 -0700 From: Ulf Zimmermann To: Matthew Sullivan Message-ID: <20050421131033.GA24555@seven.alameda.net> References: <4267A1CF.3080903@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4267A1CF.3080903@uq.edu.au> Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.10-RELEASE-p2 User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 13:10:34 -0000 On Thu, Apr 21, 2005 at 10:51:27PM +1000, Matthew Sullivan wrote: > Hey all, > > I've been reading about problems with HP/Compaq's regarding launching of > second CPUs on SMP systems. > > I've been through the BIOS settings and there seems to be no settings to > change the APCI table etc.... > > Now one thing that does seem common, when I have BIOS's with MP table > version set to 1.4 FreeBSD doesn't report the second CPU being launched > (even though it is seen in the acpidump).... When I set the BIOS to > version 1.2 of the MP table the second CPU is reported and launched. > > Now the Compaq DL380's I have done seem to have the ability to set 1.4 > or 1.2 of the table ... mptable reports 1.4... (below) > > Any suggestions on how to launch the second CPU...? > It would help to tell which version of DL380, there is Generation 1 through 4 now. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 13:16:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3673F16A4CE for ; Thu, 21 Apr 2005 13:16:14 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B882343D45 for ; Thu, 21 Apr 2005 13:16:13 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFA00D0FSVQSB@nemesis.sorbs.net> for freebsd-current@freebsd.org; Thu, 21 Apr 2005 23:16:39 +1000 (EST) Date: Thu, 21 Apr 2005 23:15:08 +1000 From: Matthew Sullivan In-reply-to: <20050421131033.GA24555@seven.alameda.net> To: ulf@Alameda.net Message-id: <4267A75C.1080609@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms040402070104070602010504; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050421131033.GA24555@seven.alameda.net> cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 13:16:14 -0000 This is a cryptographically signed message in MIME format. --------------ms040402070104070602010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ulf Zimmermann wrote: >It would help to tell which version of DL380, there is Generation 1 through >4 now. > > Sorry, it's a DL380R1 Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040402070104070602010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMTEzMTUwOFowIwYJKoZIhvcNAQkEMRYEFCbv60Pbf8cv5bQg L7J+mymUyTpOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQB4/rlM88Diy4qzAjfsKjATsKVnAfQPz0OXjhUlovg2cKW8JfHNfZ5oXyLAZK06YSlHm pjRmrYniYloHdph6h08AAAAAAAA= --------------ms040402070104070602010504-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 13:59:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C4D316A4CE for ; Thu, 21 Apr 2005 13:59:40 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44CC543D1F for ; Thu, 21 Apr 2005 13:59:40 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DOcD0-0003Is-00; Thu, 21 Apr 2005 15:59:10 +0200 Date: Thu, 21 Apr 2005 15:59:10 +0200 To: Matthew Sullivan Message-ID: <20050421135910.GR2298@poupinou.org> References: <4267A1CF.3080903@uq.edu.au> <20050421131033.GA24555@seven.alameda.net> <4267A75C.1080609@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4267A75C.1080609@uq.edu.au> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-current@freebsd.org cc: ulf@Alameda.net Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 13:59:40 -0000 On Thu, Apr 21, 2005 at 11:15:08PM +1000, Matthew Sullivan wrote: > Ulf Zimmermann wrote: > > >It would help to tell which version of DL380, there is Generation 1 through > >4 now. > > > > > Sorry, it's a DL380R1 There are some bios upgrade that may help IIRC. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 14:31:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A2916A4CE for ; Thu, 21 Apr 2005 14:31:40 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEFC843D2F for ; Thu, 21 Apr 2005 14:31:39 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFA00D0NWDGSB@nemesis.sorbs.net> for freebsd-current@freebsd.org; Fri, 22 Apr 2005 00:32:04 +1000 (EST) Date: Fri, 22 Apr 2005 00:30:33 +1000 From: Matthew Sullivan In-reply-to: <20050421135910.GR2298@poupinou.org> To: Bruno Ducrot Message-id: <4267B909.9070501@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms060403080802090806060806; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050421131033.GA24555@seven.alameda.net> <4267A75C.1080609@uq.edu.au> <20050421135910.GR2298@poupinou.org> cc: freebsd-current@freebsd.org cc: ulf@Alameda.net Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 14:31:40 -0000 This is a cryptographically signed message in MIME format. --------------ms060403080802090806060806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruno Ducrot wrote: >On Thu, Apr 21, 2005 at 11:15:08PM +1000, Matthew Sullivan wrote: > > >>Ulf Zimmermann wrote: >> >> >> >>>It would help to tell which version of DL380, there is Generation 1 through >>>4 now. >>> >>> >>> >>> >>Sorry, it's a DL380R1 >> >> > >There are some bios upgrade that may help IIRC. > > > AFAIK I have the latest BIOS in one and not the other - neither work. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms060403080802090806060806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMTE0MzAzM1owIwYJKoZIhvcNAQkEMRYEFDsfP1495Qlu29qG deLDzrVQvaX5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQHl7dCoZ4n2HNWLkcm3C5IqJX7fqa1JVUJZwTqQxy76e921ug/8jbh2I8pPYAlujlSBZ Lo+1wtvPXXjmMgLZW/wAAAAAAAA= --------------ms060403080802090806060806-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 16:06:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B462216A4CE for ; Thu, 21 Apr 2005 16:06:52 +0000 (GMT) Received: from peedub.jennejohn.org (J9c4b.j.pppool.de [85.74.156.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD4843D1F for ; Thu, 21 Apr 2005 16:06:51 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.3/8.11.6) with ESMTP id j3LG6gbc007250; Thu, 21 Apr 2005 18:06:42 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Lars Engels In-Reply-To: Message from Lars Engels <20050420221903.GA738@bart.bsd-geek.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Apr 2005 18:06:42 +0200 From: Gary Jennejohn cc: current@freebsd.org Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 16:06:52 -0000 Lars Engels writes: > Hi all! > > I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. > Compilation and installation went fine, but when I try to start firefox, > gkrellm and even portupgrade I get the following error message: > /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol > "i386_get_gsbase" > > Is there something i have not spotted in UPDATING? > > System: FreeBSD 6.0-CURRENT #5: Wed Apr 20 23:21:11 CEST 2005 > It's not in UPDATING, but a change was recently made (can't say exactly when) which affects %gs/%fs. If you're using -current then you really should watch the commits, too! You'll have to recompile these ports, I suspect. Interestingly, my old gkrellm still runs just fine with a new world from yesterday, but I had to reinstall transcode. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 17:15:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFB0216A4CE; Thu, 21 Apr 2005 17:15:13 +0000 (GMT) Received: from hex.databits.net (hex.databits.net [216.118.117.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 473FA43D48; Thu, 21 Apr 2005 17:15:13 +0000 (GMT) (envelope-from will@csociety.org) Received: by hex.databits.net (Postfix, from userid 1001) id AC4A857AE8; Thu, 21 Apr 2005 12:15:12 -0500 (CDT) Date: Thu, 21 Apr 2005 12:15:12 -0500 From: Will Andrews To: Rex Roof Message-ID: <20050421171512.GU1693@hex.databits.net> Mail-Followup-To: Rex Roof , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <6afb69aa05042008065db9d0cb@mail.gmail.com> <6afb69aa05042008093d6d59d0@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ixNtouB4hv1hrEz3" Content-Disposition: inline In-Reply-To: <6afb69aa05042008093d6d59d0@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: gvinum during bootup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 17:15:13 -0000 --ixNtouB4hv1hrEz3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2005 at 11:09:50AM -0400, Rex Roof wrote: > I'm running a FreeBSD6 machine current as of a few days ago and I'm > working on a gvinum configuration, I couldn't find any place where it > referenced gvinum on startup so after fussing around with the rc > system a little, I wrote an /etc/rc.d/gvinum script that looks like geom_vinum only needs the module loaded on startup to work. So add geom_vinum_load=3D"YES" to your loader.conf. That's why there isn't any rc.d/gvinum script, like there is for old-vinum. This should probably be documented... Regards, --=20 wca --ixNtouB4hv1hrEz3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCZ9+gF47idPgWcsURAsG/AJ9AXYqki1Qx1JwVi8bHYkCzfRuyWACfXbza UuLHQ6MteNiOgx00y5g1uU4= =FvFG -----END PGP SIGNATURE----- --ixNtouB4hv1hrEz3-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 17:22:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C5A316A4CE for ; Thu, 21 Apr 2005 17:22:30 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87F6043D31 for ; Thu, 21 Apr 2005 17:22:29 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOfIK-0004yP-TQ for freebsd-current@freebsd.org; Thu, 21 Apr 2005 19:16:52 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 19:16:52 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 19:16:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Thu, 21 Apr 2005 10:20:31 -0700 Lines: 156 Message-ID: References: <20050420214259.GA46821@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.8.2 Sender: news Subject: Re: LOR/page fault panic vfs_mountroot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 17:22:30 -0000 Kris Kennaway wrote: > On Wed, Apr 20, 2005 at 01:04:08PM -0700, othermark wrote: >> Current as of a few minutes ago. LOR/panic. Dual processor box. >> >> kernel has vlan, ipfw, and dummynet enabled, but this doesn't >> look like the problem. >> >> Curiously, booting single user and mounting root there doesn't >> panic, but it does panic if you try to 'exit' to multiuser. >> >> [...] >> Timecounters tick every 1.000 msec >> ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding >> disabled, default to accept, logging disabled >> ad0: 19092MB at ata0-master UDMA33 >> acd0: CDROM at ata1-master UDMA33 >> ATA PseudoRAID loaded >> SMP: AP CPU #1 Launched! >> Trying to mount root from ufs:/dev/ad0s1a >> lock order reversal >> 1st 0xc0a2d740 vm page queue mutex (vm page queue mutex) >> @ /usr/src/sys/kern/vfs_bio.c:1485 >> 2nd 0xc25e4d6c vnode interlock (vnode interlock) >> @ /usr/src/sys/kern/vfs_subr.c:1992 > > This has been reported a half-dozen times or so. > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 01 >> fault virtual address = 0x4ac0c092 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0703f88 >> stack pointer = 0x28:0xe5092b78 >> frame pointer = 0x28:0xe5092b78 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 73 (sysctl) >> [thread pid 73 tid 100060 ] >> Stopped at strlen+0x8: cmpb $0,0(%edx) >> db> show alllocks >> Process 73 (sysctl) thread 0xc23b2600 (100060) >> exclusive sx sysctl lock r = 0 (0xc09d1c60) locked >> @ /usr/src/sys/kern/kern_sysctl.c:1335 >> exclusive sleep mutex Giant r = 0 (0xc09d1620) locked >> @ /usr/src/sys/kern/kern_sysctl.c:1273 > > I think this one might be new. Please obtain a debugging traceback. Not too familiar with ddb, at least not enough to know which address/offset to expand to see which oid is causing the failure. db> where Tracing pid 73 tid 100060 td 0xc23b2600 strlen(4ac0c092,c091efb7,1,c09d1228,0) at strlen+0x8 sysctl_sysctl_name(c096d3a0,e5092c74,3,e5092bfc,e5092bfc) at sysctl_sysctl_name+0x10f sysctl_root(0,e5092c6c,5,e5092bfc,c23b2600) at sysctl_root+0x154 userland_sysctl(c23b2600,e5092c6c,5,bfbfdc70,bfbfdbfc) at userland_sysctl+0x13c __sysctl(c23b2600,e5092d04,18,3ff,6) at __sysctl+0xb7 syscall(bfbf003b,bfbf003b,bfbf003b,bfbfdbfc,bfbfdc00) at syscall+0x2a0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280be67f, esp = 0xbfbfdb7c, ebp = 0xbfbfdba8 --- (gdb) l *syscall+0x2a0 0xc088cc50 is in syscall (/usr/src/sys/i386/i386/trap.c:951). 946 947 STOPEVENT(p, S_SCE, narg); 948 949 PTRACESTOP_SC(p, td, S_PT_SCE); 950 951 error = (*callp->sy_call)(td, args); 952 } 953 954 switch (error) { 955 case 0: (gdb) l *__sysctl+0xb7 0xc0695487 is in __sysctl (/usr/src/sys/kern/kern_sysctl.c:1275). 1270 if (error) 1271 return (error); 1272 1273 mtx_lock(&Giant); 1274 1275 error = userland_sysctl(td, name, uap->namelen, 1276 uap->old, uap->oldlenp, 0, 1277 uap->new, uap->newlen, &j, 0); 1278 if (error && error != ENOMEM) 1279 goto done2; (gdb) l *userland_sysctl+0x13c 0xc069563c is in userland_sysctl (/usr/src/sys/kern/kern_sysctl.c:1340). 1335 SYSCTL_LOCK(); 1336 1337 do { 1338 req.oldidx = 0; 1339 req.newidx = 0; 1340 error = sysctl_root(0, name, namelen, &req); 1341 } while (error == EAGAIN); 1342 1343 if (req.lock == REQ_WIRED && req.validlen > 0) 1344 vsunlock(req.oldptr, req.validlen); (gdb) l *sysctl_root+0x154 0xc06953b4 is in sysctl_root (/usr/src/sys/kern/kern_sysctl.c:1241). 1236 error = mac_check_system_sysctl(req->td->td_ucred, oid, arg1, ar g2, 1237 req); 1238 if (error != 0) 1239 return (error); 1240 #endif 1241 error = oid->oid_handler(oid, arg1, arg2, req); 1242 1243 return (error); 1244 } 1245 (gdb) l *sysctl_sysctl_name+0x10f 0xc069448f is in sysctl_sysctl_name (/usr/src/sys/kern/kern_sysctl.c:555). 550 continue; 551 552 if (req->oldidx) 553 error = SYSCTL_OUT(req, ".", 1); 554 if (!error) 555 error = SYSCTL_OUT(req, oid->oid_name, 556 strlen(oid->oid_name)); 557 if (error) 558 return (error); 559 (gdb) l *strlen+0x8 0xc0703f88 is in strlen (/usr/src/sys/libkern/strlen.c:41). 36 strlen(str) 37 const char *str; 38 { 39 register const char *s; 40 41 for (s = str; *s; ++s); 42 return(s - str); 43 } -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 17:52:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FA1416A4CE; Thu, 21 Apr 2005 17:52:26 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 497BF43D49; Thu, 21 Apr 2005 17:52:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3LHs5hV095764; Thu, 21 Apr 2005 11:54:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4267E78B.7010409@samsco.org> Date: Thu, 21 Apr 2005 11:48:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org Content-Type: multipart/mixed; boundary="------------040901080907080607090507" X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Subject: FreeBSD Status Report Jan-Mar 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 17:52:26 -0000 This is a multi-part message in MIME format. --------------040901080907080607090507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------040901080907080607090507 Content-Type: text/plain; name="report-jan-2005-mar-2005.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="report-jan-2005-mar-2005.txt" January-April 2005 Status Report Introduction The first quarter of 2005 has been extremely active in both FreeBSD-CURRENT and -STABLE. With FreeBSD 5.4 in the final RC stage and an anticipated branch of FreeBSD-6 this summer we have seen a lot of performance improvements in 5 and a couple of exciting new features in 6. The report turnout was extremely good and it seems that the webform provided by Julian Elischer has made it more enjoyable to write reports. Many thanks to Julian for providing this. We also like to get your attention to the open tasks section provided in some reports. On special note, please take a look at the report about the upcoming BSDCan in Ottawa. There will be lots of interesting FreeBSD related talks and activities. If you enjoy reading these reports, you will love the conference. See you there! Thanks to all the reporters, we hope you enjoy reading. _________________________________________________________________ Projects * Common Address Redundancy Protocol - CARP * FreeBSD Java Project * FreeBSD Release Engineering * GELI - GEOM class for providers encryption * GSHSEC - GEOM class for handling shared secret * Secure Updating Documentation * FreeBSD Dutch Documentation Project Kernel * ATAPI/CAM * Coverity Code Analysis * cpufreq * drm * Filesystem journalling for UFS * Infrastructure Cleanup * Interrupt Latency * Low-overhead performance monitoring for FreeBSD * Many subdirs for UFS * Status Report for FreeBSD ATA driver project * Storage driver SMPng locking Network infrastructure * Dingo * IPv6 Support for IPFW * Move ARP out of routing table * netgraph(4) status report * Removable interface improvements. * Support for telephone hardware (aka Zaptel) * Wireless Networking Support Userland programs * libthread * Pipe namespace added to portalfs Architectures * ARM Support for TS-7200 * PowerPC Port * XenFreeBSD - FreeBSD on Xen Ports * FreshPorts * Ports Collection * Update of the Linux userland infrastructure Vendor / 3rd Party Software * OpenBSD packet filter - pf * twa driver Miscellaneous * BSDCan * FreeBSD Security Officer and Security Team * IMUNES - a FreeBSD based kernel-level network topology emulator _________________________________________________________________ ARM Support for TS-7200 URL: http://www.embeddedarm.com/epc/ts7200-spec-h.html URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/jmg /arm&HIDEDEL=NO URL: http://people.freebsd.org/~jmg/dmesg.ts7200 Contact: John-Mark Gurney I have been working on getting FreeBSD/arm running on the TS-7200. So far the board boots, and has somewhat working ethernet (some unexplained packet loss). I can netboot from a FreeBSD/i386 machine, and I can also mount msdosfs's on CF. Open tasks: 1. Figuring out why some small packets transmit with error 2. EP93xx identification information to properly attach various onboard devices _________________________________________________________________ ATAPI/CAM Contact: Thomas Quinot ATAPI/CAM integration with the new ATA (mkIII) framework is now completed. ATAPI/CAM is now available as a loadable module (atapicam.ko). It is also independant from the native ATAPI drivers again, as was the case before mkIII. Thanks to Scott Long and Søren Schmidt for their participation in the integration work. _________________________________________________________________ BSDCan URL: http://www.bsdcan.org/ Contact: Dan Langille BSDCan made a strong debut in 2004 . The favorable reception gave us a strong incentive for 2005 . We have been rewarded with a very interesting program and a higher rate of registrations. Percentage-wise, we have more Europeans than last year as they have decided that the trip across the Atlantic is worth taking. We know they won't be disappointed. See you at BSDCan 2005! Open tasks: 1. volunteers needed for the conference _________________________________________________________________ Common Address Redundancy Protocol - CARP URL: http://www.freebsd.org/cgi/man.cgi?query=carp&manpath=FreeBSD+6.0-curr ent URL: http://people.freebsd.org/~mlaier/CARP/ Contact: Max Laier Contact: Gleb Smirnoff CARP is an alternative to VRRP. In contrast to VRRP it has full support for IPv6 and uses crypto to protect the advertisements. It was developed by OpenBSD due to concerns that the HSRP patent might cover VRRP and CISCO might defend its patent. CARP has, since then, improved a lot over VRRP. CARP has been committed to HEAD and MFCed to RELENG_5. It will be available in upcoming 5.4-RELEASE. Big thanks to all users who provided testing and reported bugs to Max and Gleb. Daniel Seuffert has donated hardware to Max for this project. Gleb's work was sponsored by Rambler . Open tasks: 1. Improve vlan(4) support. Test ng_eiface(4). 2. Improve locking, consider removing interface layer. _________________________________________________________________ Coverity Code Analysis URL: http://www.coverity.com/ Contact: Sam Leffler There has been an ongoing effort to review the kernel source code using Coverity's source code analysis tools (http://www.coverity.com). These tools check for a variety of problems such as null pointer dereference, use-after-free of allocated variables, invalid array references, etc. This work is a joint project between FreeBSD and Coverity. Two passes have been completed over the 6-current kernel source code base and all significant problems have been corrected. These runs were done in February and March of this year. A few reports of minor problems await response from outside groups and will be resolved in time for the first 6.x release. Another analysis run over the kernel will happen soon. We are looking for a way to use these tools on a regular basis as they have been helpful in improving the code base. Thanks to Coverity for their help and especially Ted Unangst. Several developers have been especially helpful in resolving reports: Poul-Henning Kamp, David Schultz, Pawel Jakub Dawidek, George V. Neville-Neil, and Matthew Dodd. _________________________________________________________________ cpufreq URL: http://www.freebsd.org/cgi/man.cgi?query=cpufreq&manpath=FreeBSD+6.0-c urrent&format=html Contact: Nate Lawson The cpufreq project was committed to 6-CURRENT in early February and has undergone bugfixes and updates. It will soon be MFCd to 5-STABLE. The cpufreq driver provides a unified kernel and user interface to CPU frequency control drivers. It combines multiple drivers offering different settings into a single interface of all possible levels. Users can access this interface directly via sysctl(8), by indicating to power_profile that it should switch settings when the AC line state changes, or by using powerd(8). For example, an absolute driver offering frequencies of 1000 Mhz and 750 Mhz combined with a relative driver offering settings of 100% and 50% would result in cpufreq providing levels of 1000, 750, 500, and 375 Mhz. Colin Percival helped with powerd(8), which provides automatic control of CPU frequencies. The adaptive mode is especially interesting since it attempts to respond to changes in system load while reducing power consumption. Current hardware drivers include acpi_perf (ACPI CPU performance states), est (Intel Enhanced SpeedStep for Pentium-M), ichss (Intel's original SpeedStep for ICH), and powernow (AMD Powernow! K7 and K8 support). Other drivers for relative hardware include acpi_throttle (ACPI CPU throttling) and p4tcc (Pentium 4 Thermal Control Circuitry) Thanks to Bruno Ducrot for the powernow driver, Colin Percival for the est driver, and the many testers who have sent in feedback. Open tasks: 1. We'd appreciate someone with a Transmeta CPU converting the existing longrun driver to the cpufreq framework. It would also be good if someone wrote a VIA Longhaul driver. See the Linux arch/i386/kernel/cpu/cpufreq directory for examples. 2. Various other architectures, including ARM, have CPU power control that could be implemented as a cpufreq driver. 3. The powerd(8) algorithm is rather simple and we'd appreciate more help in testing it and alternative algorithms with various workloads. The -v flag causes powerd to report frequency transitions and print a summary of total energy used upon termination. This should help testers profile their algorithms. _________________________________________________________________ Dingo URL: http://people.freebsd.org/~gnn/Dingo/notebook/60.html URL: http://zoo.unixdaemons.com/index.php?blog=7 Contact: George Neville-Neil On the protocol conformance tool I have finally made some progress getting a scriptable packet library using libnet, and SWIG. This will hopefully become a port that can then be used to do conformance testing on protocol stack changes. Qing Li has separately taken up the ARP rewrite and that will be taken out of the Dingo project pages. Open tasks: 1. Many :-) _________________________________________________________________ drm URL: http://r300.sourceforge.net/ Contact: Eric Anholt A DRM update was finally committed to -current on 2005-04-15, after jhb@ did the necessary fix to vm_mmap. New development drivers were added for mach64 and r300 (see URL for info). The nearly-finished code for savage and i915 were also added, but left disconnected from the build. However, the most visible change is likely the support for texture tiling, color tiling, and HyperZ on Radeons, which (with updated userland) likely provide a 50-75% framerate increase in many applications. Open tasks: 1. Find someone with newbus knowledge to figure out why the i915 won't attach to drmsub0. 2. Finish porting the savage driver. 3. Integrate busdma code from Tonnerre (NetBSD). _________________________________________________________________ Filesystem journalling for UFS URL: http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/scot tl/ufsj Contact: Scott Long It's time to bite the bullet and admit that fsck is no longer scalable for modern storage capacities. While a healthy debate can still be had on the merits and data integrity guarantees of journalling vs. SoftUpdates, the fact that SoftUpdates still requires a fsck to ensure consistency of the filesystem metadata after an unclean shutdown means uptime is lost. While background fsck is available, it saps system performance and stretched the fsck time out to hours. Journalling provides a way to record transactions that might not have fully been written to disk before the system crashed, and then quickly recover the system back to a consistent state by replaying these transactions. It doesn't guarantee that no data will be lost, but it does guarantee that the filesystem will be back to a consistent state after the replay is performed. This contrasts to SoftUpdates that re-arranges metadata updates so that inconsistencies are minimized and easy to recover from, though recovery still requires the traditional full filesystem scan. Journalling is a key feature of many modern filesystems like NTFS, XFS, JFS, ReiserFS, and Ext3, so the ground is well covered and the risks for UFS/FFS are low. I'm aware that groups from CMU and RPI have attempted similar work in the past, but unfortunately the work is either very outdates, or I haven't had any luck in contacting the groups. Is this absence, I've decided to work on this project myself in hopes of having a functional prototype in time for FreeBSD 6.0. The approach is simple and journals full metadata blocks instead of just deltas or high-level operations. This greatly simplifies the replay code at the cost of requiring more disk space for the journal and more work within the filesystem to identify discreet update points. An important design consideration is whether to make the journal data and code compatible with the UFS2 filesystem, or to start a new UFS3 derivative. Since the latter presents a very high barrier to adoption for most people, I'm going to try to make it a compatible option for UFS2. This means that the journal blocks will likely appear as an unlinked file to legacy filesystem and fsck code, and will be treated as such. This will allow seamless fallback to using fsck, though once the unlinked journal data blocks are reclaimed by fsck, the user will have to take action to re-create the journal file again. One key piece of journalling is ensuring that each journal transaction is fully written to disk before the associated metadata blocks are written to the filesystem. I plan to adopt the buffer 'pinning' mechanism from Alexander Kabaev's XFS work to assist with this. This will allow the journalling subsystem fine-grained control over which blocks get flushed to disk by the buffer daemon without having to further complicate the UFS/FFS code. One consideration is how Softupdates falls into this and whether it is multually exclusive of journalling or if it can help provide transaction ordering functionality to the journal. Research here is on-going. Some preliminary work can be found in Perforce in the //depot/user/scottl/ufsj/... tree or at the URL provided. Hopefully this will quickly accelerate. _________________________________________________________________ FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/doc/nl/books/handbook URL: http://www.evilcoder.org/freebsd_html/ URL: http://www.evilcoder.org/content/section/6/39/ Contact: Remko Lodder The FreeBSD Dutch Documentation Project is a ongoing project in translating the English documentation to the Dutch language. Currently we have translated almost the entire handbook, and more to come. If you want to help out by review the Dutch documents, or you want to help translating the remainders of the handbook or other documents, feel free to contact me at remko@FreeBSD.org Open tasks: 1. Translate the English handbook, then review the Dutch handbook 2. Translate the English FAQ, then review the Dutch FAQ 3. Translate the English Articles, then review the Dutch Articles _________________________________________________________________ FreeBSD Java Project URL: http://www.FreeBSD.org/java/ Contact: Greg Lewis Contact: Alexey Zelkin The FreeBSD Java Project released its initial support for JDK 1.5.0 with patch set 1 "Sabretooth" in January. The initial release featured support for both FreeBSD 5.3/i386 and 5.3/amd64. Since then preliminary support for FreeBSD 4.11/i386 has been added and several bug fixes have been made. Updates in the coming months will add support for the browser plug in and Java Web Start, which were not in the initial release. Open tasks: 1. Volunteers to look into some serious problems with JDK 1.5.0 on FreeBSD 4.x _________________________________________________________________ FreeBSD Release Engineering URL: http://www.freebsd.org/releng Contact: RE Team FreeBSD 4.11, the final formal release of the 4.x series, was released on 25 Jan 2005. Many thanks to the all of the developers and users over the past 5 years who made it successful. While no more releases are planned, the security team will continue to support it through security update patches until 2007. Developers are also free to commit bug fixes and low-risk features to the RELENG_4 branch for the foreseeable future. FreeBSD 5.4 is going through its final release candidate stages and is expected to be released in late April. Its focus is mostly bug fixes and minor feature and performance improvements, so it is an excellent target for those looking to upgrade from previous versions or to give FreeBSD a try for the first time. FreeBSD 5.5 will be release in about 4-6 months after 5.4. FreeBSD 6.0 is rapidly approaching also. In contrast to FreeBSD 5.0, the goal is to take a more incremental approach to major changes, and not wait for years to get as many features in as possible. FreeBSD 6.0 will largely be an evolutionary change from the 5.x series, with the largest changes centered around multi-threading and streamlining the filesystem and device layers. Feature freeze and code freeze for 6.0 are coming up in May and June, and we hope to have 6.0 stable and ready for release in July or August. The release engineering team has also started doing monthy informal snapshots of the 6-CURRENT and 5-STABLE trees. These are intended to increase the exposure of new features and get more users involved in testing and providing feedback. Snapshots can be found at http://www.freebsd.org/snapshots. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff -listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In January 2005, Warner Losh (Security Officer Emeritus) stepped down from the FreeBSD Security Team in order to better devote his time to other projects. In March, Colin Percival was named as a second Deputy Security Officer, joining Dag-Erling Smørgrav in that position. The current Security Team membership is published on the web site. So far in 2005, four security advisories have been issued concerning problems in the base system of FreeBSD, three of which were specific to FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and the Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection. As of April 17, 127 entries have been added in 2005 bringing the FreeBSD VuXML file up to a total of 422 entries. In the past months both the VuXML web site and the FreshPorts VuXML integration have been improved. The VuXML web site has had a face lift and, among other things, each package now has a separate web page which lists all documented vulnerabilities for the particular package. CVE information is now also included directly on the VuXML web site. Finally, the first few months of 2005 also saw FreeBSD 4.8 -- the first release to be offered "extended support" -- reach its designated End of Life. The currently supported releases are FreeBSD 4.10, 4.11, and 5.3. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille This is the first status report for FreshPorts. FreshPorts started in early 2000 and now contains over 170,000 commits. FreshPorts is primarily concerned with port commits, but actually processes and records all commits to the FreeBSD source tree. Its sister site, FreshSource uses the same database as FreshPorts but has a wider reporting scope. In recent months, FreshPorts has been enhanced to process and include VuXML information. In addition, RESTRICTED and NO_CDROM have been added to list of things that FreshPorts keeps track of. For unmantained ports, we recently added this message: There is no maintainer for this port. Any concerns regarding this port should be directed to the FreeBSD Ports mailing list via ports@FreeBSD.org FreshPorts, with direct and indirect support from the FreeBSD community, continues to evolve and to provide a great tool for users and developers alike. Open tasks: 1. Provide a copy/paste method for updating watch lists 2. improvement of query times for "People watching this port, also watch" 3. pagination of commits within a port 4. pagination of watch lists 5. create an RSS feed for individual watch lists _________________________________________________________________ GELI - GEOM class for providers encryption URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd /geom%5fclasses/sys/geom/eli&HIDEDEL=NO URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd /geom%5fclasses/sbin/geom/class/eli&HIDEDEL=NO Contact: Pawel Jakub Dawidek GELI is a GEOM class used for GEOM providers encryption. I decided to work on this, as I needed some feature, which cannot be found in similar projects. Here is the list of features, I found interesting: * makes use of crypto(9) * if there is a crypto hardware available, GELI will run cryptography on it automatically; if not, it starts dedicated kernel thread and do crypto software work in there * supports many cryptographic algorithms (AES, Blowfish, 3DES) * is able to take key components from many sources at once (user entered passphrase, random bits from a file, etc.) * allows to encrypt root partition * user will be asked for the passphrase before root file system is mounted * uses "PKCS #5: Password-Based Cryptography Specification Version 2.0" for user passphrase protection (optional) * allows to use two independent keys (e.g. "user key" and "company key") * is fast * GELI does simple sector-to-sector encryption * allows to backup/restore Master Keys, so when user have to quickly destroy keys, it is able to get the data back by restoring keys from the backup * provider can be configured at attach time to automatically detach on last close (so user don't have to remember to detach after unmounting file system) * allows to attach provider with a random, one-time keys * useful for swap partitions and temporary file systems Open tasks: 1. Code audit/review is more than welcome! _________________________________________________________________ GSHSEC - GEOM class for handling shared secret URL: http://www.freebsd.org/cgi/man.cgi?query=gshsec&apropos=0&sektion=0&ma npath=FreeBSD+6.0-current&format=html Contact: Pawel Jakub Dawidek GSHSEC is a GEOM class used for handling shared secret data between multiple GEOM providers. For every write request, SHSEC class splits the data using XOR operation with random data, so N-1 providers gets just random data and one provider gets the data XORed with the random data from the other providers. All of the configured providers must be present in order to reveal the secret. The class is already committed to HEAD and RELENG_5 branches. _________________________________________________________________ if_bridge from NetBSD URL: http://www.fud.org.nz/~andy/if_bridge.diff Contact: Andrew Thompson This project aims to import the bridging code and interface from NetBSD and OpenBSD. The bridge is a cloned interface which can be modified by ifconfig and brconfig. It supports assigning an IP address directly to the bridge (e.g. bridge0) instead of one of the member interfaces, and can be used with tcpdump to inspect the bridged packets. The code also supports spanning tree (802.1D) for loop detection and link redundancy. Any pfil(9) packet filter can be used to filter the bridged packets. Open tasks: 1. Testing performance and functionality against the existing bridge code. Testers welcome! _________________________________________________________________ IMUNES - a FreeBSD based kernel-level network topology emulator URL: http://www.imunes.net/ Contact: Miljenko Mikuc Contact: Marko Zec IMUNES is a scalable kernel-level network topology emulator based on FreeBSD. In IMUNES each virtual node operates on its private instance of network stack state variables, such as routing tables, interface addresses, sockets, ipfw rules etc. Most if not all existing FreeBSD application binaries, including routing protocol daemons such as quagga or XORP, can run unmodified within the context of virtual nodes with no noticeable performance penalty. Complex network topologies can be constructed by connecting the virtual nodes through netgraph-based link-layer paths. A GUI tool allows for simple and intuitive network topology specification, deployment and management. The current version of IMUNES is based on FreeBSD 4.11-RELEASE and supports IPv4. _________________________________________________________________ Infrastructure Cleanup Contact: Warner Losh Contact: Takahashi Yoshihiro Unglamorous cleanup of the code base continues. The focus of recent efforts have been to reduce the number of machine #ifdefs that are in the machine independent code. In addition, we're also trying to increase code sharing between pc98 and i386 ports and reduce the number of #ifdef PC98 instances in the tree. In addition, a number of cleanup tasks are underway for different parts of the kernel that are more complicated than necessary. Recently, the pccard code's allocation routines were simplified to reassign ownership of resources more directly than before. The search is on for other areas that can benefit from cleanup. Open tasks: 1. On pc98, there's no such thing as an ISA bus. It is desirable to move to having cbus appear in the probe messages. This would also allow for additional segregation of pc98 specific code in the drivers and eliminate many ifdefs. Ideally, isa and cbus would share a common newbus ancestor class so their similarities can be exploited (they both have PNPBIOS enumeration methods, for example). 2. cbus devices can have complicated resources. There's support for vectors of resources. Yet there's no support for populating a vector of resources from the plug and play information. Doing so would help the complex world of pc98 a lot, and the odd edge cases in i386 (floppy, ata) a little. 3. The hints mechanism provides a way to associate hardware with drivers and resource that would otherwise be completely unknown to the system. A refinement in the hints mechanism to allow matching of driver instances to resources is desirable. This would allow one to hardwire sio0 to 0x2f8, even when the serial device in the plug and play resource list (or acpi resource list) is listed second. A further refinement could also be wiring sio0 to "port B" as defined by acpi or some other enumeration method. Chances are good that these seemingly related concepts may need separate implementations due to the decision points for unit assignment. 4. Pccard, cardbus and usb probe their devices after interrupts are enabled. It would be desirable to hook into new kernel APIs to allow the mounting of root to be put off until those systems know that they are done with their initial probe of the devices present at boot. _________________________________________________________________ Interrupt Latency Contact: Warner Losh I've setup a test system to measure interrupt latency on FreeBSD 5.3 and current. So far I've measured the baseline latency for a 300MHz embedded cyrix based single board computer. I've tried a number of different strategies to optimize the interrupt path. Most of these strategies resulted in some improvement of the time it takes to get from the start of the interrupt servicing to the driver's ISR. These improvements turned out to be about 1-2% of the processing times on this single board computer, but a wash on faster machines. However, the time between when the interrupt should happen, and when FreeBSD starts to service the interrupt is the dominant factor in these measurements. Despite the fact that these are fast interrupt handlers (so the scheduler is out of the loop), I routinely see average latencies of 18us, with large variations (on the order of 5us standard deviation). Open tasks: 1. I need to measure the latencies with 4.x and current to characterize the differences more precisely. I'm especially interested in the effects on interrupt latency that the elimination of mixed mode will cause. 2. I need to characterize different parts of our ISR routines to see if some of the variation I've seen so far can be reduced by improved coding techniques. 3. I need to re-run my tests with 5.4 and summarize my results in a paper. _________________________________________________________________ IPv6 Support for IPFW URL: http://lists.freebsd.org/pipermail/cvs-all/2005-April/116671.html Contact: Brooks Davis In April 18th, I committed support for IPv6 to IPFW. This support was written by two student of Luigi's, Mariano Tortoriello and Raffaele De Lorenzo. I updated it to use PFIL_HOOKS and fixed a few minor issues. As of this commit, IP6FW should be considered deprecated in favor of IPFW. It should be possible to MFC this change to 5.x, but that is not currently planned. Open tasks: 1. Testing. 2. IP6FW to IPFW migration guide. 3. Patches relative to 5-STABLE. _________________________________________________________________ libthread Contact: David Xu libthread is a pure 1:1 threading library, it had stayed in my perforce branch for a long time, recent it was imported into source tree and replaced libthr. The purpose of the work is to improve 1:1 threading on FreeBSD, the library is designed in mind that simplest is best, currently it can run almost all of the applications libpthread can run, but gives you better SMP performance. The library size is smaller than libpthread. Currently it supports i386, AMD64, sparc64 and ia64 and may support alpha, powerpc and arm. I didn't do many tests on sparc64 and ia64, I only tested it on FreeBSD cluster machines. For i386, I always used LDT, but know that Peter committed GDT code, and now there is no 8191 threads limitation anymore. libthread_db was updated to support debugging the new libthr. It is an assistant library used by gdb to debug threaded process, that understands internal detail of thread libraries. I have improved it a bit to support event reports for libthr, currently it can report thread creation and death events. That means a thread that was created and died will be reported to the user regardless if you are tracking it or not. Open tasks: 1. I am working on thread creation performance, currently it needs considerable number of libc functions and syscalls to create a thread, I would like to introduce a syscall to create a thread in atomicaly. That means one syscall will setup thread entry, tls, and signal mask and PTHREAD_SCOPE_PROCESS/SYSTEM; in future maybe even CPU affinity masks, when userland entry code is executed, the thread is already fully setup. 2. Process shareable synchronization objects. In Current FreeBSD does not support this specification. The idea about the shareable mutex and others is like other systems did, one can use mmap() to create a shared memory page, and put a pthread synchronization object in the page, multiple processes use the shared object to control resource access. I am not working on it, if someone is interested, please let me know. _________________________________________________________________ Low-overhead performance monitoring for FreeBSD URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement Contact: Joseph Koshy Many modern CPUs have on-chip performance monitoring counters (PMCs) that can be used to count low-level hardware events like instruction retirals, branch mispredictions, cache and TLB misses and the like. PMC architectures and capabilities vary between CPU vendors and between CPU generations from the same vendor, making the creation of portable applications difficult. This project attempts to provide a uniform API for applications to use, and the necessary infrastructure to "virtualize" and manage the available PMC hardware resources. The creation of performance analysis tools that use this infrastructure is also part of the project's goals. Work since the last status report: * Support for Intel Pentium-Pro/Pentium-II/Pentium-III/Pentium-M/Celeron style PMCs has been added. * The Pentium-4/HTT machine dependent layer has been overhauled. * A Python language interface to the C library interface pmc(3) has been written. * Many bugs have been fixed and documentation has been updated. Open tasks: 1. The code needs to be tested on Intel Pentium-M, Celeron, Pentium II and Pentium Pro CPUs. _________________________________________________________________ Many subdirs for UFS URL: http://groups-beta.google.com/group/muc.lists.freebsd.fs/browse_frm/th read/a36d1143d695287e/40cad00cf2c0823b?hl=en#40cad00cf2c0823b Contact: David Malone I'm currently looking at the limit on the number of subdirectories a directory can have in UFS. There is currently a limit of 32K subdirectories because of the 16 bit link count field in both struct stat and the on-disk inode format. The thread above shows that dirhash provides acceptable performance for directories with 100k subdirectories using a prototype patch. Two options for allowing many subdirectories seem to exist: changing the link counting scheme for directories and expanding the link count field. The prototype patch implements the first scheme and there are plans to investigate the second scheme (which may require an ABI change). _________________________________________________________________ Move ARP out of routing table URL: http://people.freebsd.org/~qingli/ Contact: Qing Li I have finished the basic functionality for both IPv4 and IPv6. The userland utilities ("arp" and "ndp") have been updated. I have tested the changes with "make buildworld". I have been testing the new code in a production environment and things appear to be stable. Gleb Smirnoff (glebius@FreeBSD.org) has provided review comments and I have incorported these feedback into the patch. I have discussed the IPv6 changes with two of the core KAME developers during the last IETF meeting in March 2005. They indicated that these changes may result in divergence from the KAME project but that is not necessarily a bad thing. Open tasks: 1. I am waiting for review feedback from my mentor Andre. I need locking experts to help me fix my giant-lock shortcut. I am hoping to send out the code for wider review soon. _________________________________________________________________ netgraph(4) status report URL: http://www.freebsd.org/cgi/man.cgi?query=ng_netflow&manpath=FreeBSD+6. 0-current URL: http://www.freebsd.org/cgi/man.cgi?query=ng_ipfw&manpath=FreeBSD+6.0-c urrent URL: http://people.freebsd.org/~glebius/totest/ng_nat/ Contact: Gleb Smirnoff This report covers period since August 2004 until April 2005. New nodes. Two new nodes have been added to base FreeBSD distribution. ng_netflow(4) node, which implements NetFlow version 5 accounting of IPv4 packets. ng_ipfw(4) node, which diverts packets from ipfw(4) to netgraph(4) and back. A well known ng_ipacct node has been added to ports tree. SMP. Nodes, which need to allocate unique names have been protected with mutex in RELENG_5, and subr_unit allocator in HEAD. Nodes, which need to run periodical jobs were reworked to use mpsafe ng_callout() API. ng_tty(4) node has been overhauled to be compatible with debug.mpsafenet=1. NetGraph ISR and callout are now declared MPSAFE in HEAD. NetGraph flow control. Two nodes ng_ether(4) and ng_cisco(4) have been improved to emit flow control messages to upstream node, when state of link changes. New link failure detection method have been introduced in ng_one2many(4) node - listening to these flow control messages from downstream. Open tasks: 1. more SMP testing of many nodes 2. review locking of graph restructuring 3. ng_nat node - an in-kernel natd(8) 4. make ng_bridge(4) multithreaded _________________________________________________________________ OpenBSD packet filter - pf URL: http://pf4freebsd.love2party.net/ URL: http://people.freebsd.org/pf37/ Contact: Max Laier OpenBSD is about to release version 3.7 . There are patches available to catch up with the development done in OpenBSD 3.6 and 3.7. These patches are in an early stage, but ready for testing, please help. Otherwise there was not much activity on pf, as it already is quite stable. Other work, such as CARP and if_bridge are having impact on pf in FreeBSD however, please see the respective reports. Open tasks: 1. Alpha/Betatesting of the 3.7 import 2. Testing with if_bridge _________________________________________________________________ Pipe namespace added to portalfs URL: http://www.spinellis.gr/blog/20050413/index.html Contact: Diomidis Spinellis A new sub-namespace, called pipe, has been added to portalfs. The pipe namespace executes the named command, starting back at the root directory. The command's arguments can be provided after the command's name, by separating them with spaces or tabs. Files opened for reading in the pipe namespace will receive their input from the command's standard output; files opened for writing will send the data of write operations to the command's standard input. The pipe namespace allows us to perform scatter gather operations without using temporary files, create non-linear pipelines, and implement file views using symbolic links. _________________________________________________________________ Ports Collection URL: http://www.freebsd.org/ports/ URL: http://portsmon.firepipe.net/index.html URL: http://www.freebsd.org/portmgr/index.html Contact: Mark Linimon As this report was being written, the 5.4 release was ongoing. A new charter for the Ports Management (portmgr) team was approved by core and has been posted at the URL above. In addition, two other new pages describe the policies of the team, and the range of QA activities both during and between releases. Due to being absent from email discussions for some time, Oliver Eikemeier (eik) was moved to non-voting status on portmgr. We have added several new and very active committers recently; this is helping us to keep the PR count low even with the large numbers of new ports that have been added. Several more iterations of infrastructure changes have been tested on the cluster and committed; see /usr/ports/CHANGES for details. Updates have occurred to x.org, GNOME, KDE, and perl. There have been some updates to the Porter's Handbook, but more sections are still in need of updates to include recent changes in practices. The ports collection now contains almost 12,750 ports. Open tasks: 1. Further progress has been made in cracking down on ports that install files outside the approved directories and/or do not deinstall cleanly (see "Extra files not listed in PLIST" on pointyhat ) and this will remain a focus area. We appreciate everyone who has sent in PRs or committed fixes. 2. Demand for new features and revisions for bsd.port.mk is still very high and the portmgr team is trying to work through them all. 3. We still have a large number of PRs that have been assigned to committers for some time (in fact, they constitute the majority). One goal of portmgr in the coming months is to try to reduce this number, and we would like to ask our committers to help us out as much as possible. _________________________________________________________________ PowerPC Port Contact: Peter Grehan Progress continues. X.Org 6.8.1 server has been up and running on a number of different Macs, and the work is being merged into 6.8.2. There have been successful installs on Mac Minis _________________________________________________________________ Removable interface improvements. URL: http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/ URL: http://www.freebsd.org/projects/dingo/ Contact: Brooks Davis This project is an attempt to clean up handling of network interfaces in order to allow interfaces to be removed reliably. Current problems include panics if Dummynet is delaying packets to an interface when it is removed. I am currently working to remove struct ifnet's from device driver structures to allow them to be managed properly upon device removal. I believe I have removed all known instances of casting a struct ifnet pointer to something else (except that that are just magic values and not real struct ifnets.) I will begin committing these changes to the tree shortly and will then add a new function if_alloc() that will allocate struct ifnets. if_detach() will be modified to destroy them. _________________________________________________________________ Secure Updating URL: http://www.daemonology.net/portsnap/ URL: http://www.daemonology.net/freebsd-update/ Contact: Colin Percival Shortly before the ports freeze for FreeBSD 5.4, I released a new version of Portsnap. In addition to being secure and more efficient than CVSup, this latest version distributes INDEX, INDEX-5, and INDEX-6 files, thereby eliminating the need to run "make fetchindex" and ensuring that the ports INDEX will match the existing ports tree. In addition, portsnap builds have now moved onto hardware managed by the FreeBSD project, thereby sharply increasing portsnap's chances of survival if I get hit by a bus. In early February hardware problems caused both FreeBSD Update and Portsnap to stop functioning for a few days, but those were resolved thanks to a server donated by layeredtech.com. I intend bring Portsnap into the FreeBSD base system before the end of the month, followed by FreeBSD Update a few months later. _________________________________________________________________ Status Report for FreeBSD ATA driver project Contact: Søren Schmidt ATA mkIII has been committed to -current after a couple of month testing as patches post on -current and 5-stable. I will continue to provide patches for 5-stable for those that need up-to-date ATA support there. Here a short rehash of what mkIII brings: ATA is now fully modular so each part can be loaded/unloaded at will to provided the wanted functionality. Much improved SATA support that support hotplug events on controllers that support it (Promise, SiS, nVidia so far) ie the system will automagically detect when SATA devices come and go and add/delete device entries etc. Much improved ATA RAID support. The ata-raid driver has been largely rewritten to take advantage of the features the improved infrastructure provides, including composite ATA operations etc. The rebuild functionality has been changed to rebuild on userland reads, so a simple dd of the entire array will get it rebuild (what atacontrol now does). This means that the resources used for this can be better tailored to the actualy usage pattern if needed. ATA RAID now supports 10+ different RAID metadata formats, so most BIOS defined ATA RAID arrays can be picked up and used. The number of metadata formats that can be created from within FreeBSD is still limitted though and is not a high priority feature right now. The lowlevel infrastructure of the ATA driver has been refined even further to support "strange" chipsets much more easily and in most case transparent to the higher levels. This to easy ports to new platforms where ATA controllers doesn't necessarily have the x86 legacy layout. Lots of bug fixes and corrections all over the driver proper. The rework of the infrastructure has revealed bugs and deficiencies that has been fixed in the process of modulerising ATA and making the infrastructure more generic, and hopefully easier to understand. The work continues to keep ATA on top of new chipsets and other advancements in the ATA camp. SATA ATAPI support is in the works and so are support for NCA/TCQ (tags). Donations of unsupported hardware is the way to get it supported as I'm way out of my budget for new hardware for the next decade or so according to my wife :) Open tasks: 1. Lots of testing wanted, especially SATA and RAID support _________________________________________________________________ Storage driver SMPng locking Contact: Scott Long Several storage drivers have been taken out from under the Giant mutex in the past few months. Thanks to sponsorship from FreeBSD Systems, Inc and ImproWare, AG, Switzerland , the LSI MegaRAID (AMR) and IBM/Adaptec ServeRAID (IPS) drivers have been locked. SMPng locking is a key step in improving the performance of system drivers in FreeBSD 5.x and beyond, and both of these drivers are showing the benefits of this. FreeBSD 5.4 will contains these improvements when it is released. Similar work is ongoing with the 3WARE Escalade (TWE) driver, and preliminary patches have been made available to testers. I hope to have this driver complete in time for the next FreeBSD release. Unfortunately, most benefits can only be gained from pure block storage drivers such as the ones mentioned here due to the SCSI subsystem in FreeBSD (CAM) not be locked itself at this time. It is possible, however, to lock a CAM sub-driver and bring the driver's interrupt handler out from under Giant for a partial gain. The Sun FAS366 SCSI driver (ESP) operates like this. Volunteers to lock other drivers or to tackle locking CAM are gladly accepted, so please contact me if you are interested. _________________________________________________________________ Support for telephone hardware (aka Zaptel) URL: http://www.digium.com/index.php?menu=hardware_products Contact: Maxim Sobolev Contact: Oleksandr Tymoshenko Contact: Max Khon During the last 2 months lot of progress has been made. Existing support for TDM400 (FXO/FXS) has been significantly improved. Drivers for PRI and BRI cards have been added and now should be considered beta-quality. Open tasks: 1. More testing of PRI/BRI drivers. 2. Add support for channelized DS3 card(s). _________________________________________________________________ twa driver URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/ URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/ Contact: Vinod Kashyap A newly re-architected twa(4) driver was committed to 6 -CURRENT on 04/12/2005. Highlights of this release are: 1. The driver has been re-architected to use a "Common Layer" (all tw_cl* files), which is a consolidation of all OS-independent parts of the driver. The FreeBSD OS specific portions of the driver go into an "OS Layer" (all tw_osl* files). This re-architecture is to achieve better maintainability, consistency of behavior across OS's, and better portability to new OS's (drivers for new OS's can be written by just adding an OS Layer that's specific to the OS, by complying to a "Common Layer Programming Interface (CLPI)" API. If there's interest in porting the 3ware driver to any other OS, you may contact ctchu at amcc.com to get a copy of the CLPI specifications. 2. The driver takes advantage of multiple processors. It does not need to be Giant protected anymore. 3. The driver has a new firmware image bundled, the new features of which include Online Capacity Expansion and multi-lun support, among others. More details about 3ware's 9.2 release can be found here: http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_N otes_Web.pdf _________________________________________________________________ Update of the Linux userland infrastructure Contact: Alexander Leidinger Contact: Emulation Mailinglist The update to RedHat 8 as discussed in the last status report went smoothly (just some minor glitches which got resolved fast). As a next step a cleanup/streamlining and the possibility of overriding the default linux base is in progress. This depends on changes which need at least one testrun on the ports build cluster, so the final date for those changes depends upon the availability of the cluster resources. Open tasks: 1. Refactoring the common RPM code into bsd.rpm.mk. 2. Determining which up-to-date Linux distribution to use as the next default linux base. Important criteria: + RPM based (to be able to use the existing infrastructure) + good track record regarding availability of security fixes + packages available from several mirror sites + available for several hardware architectures (e.g. i386, amd64, sparc64; Note: not all architectures have a working linuxolator for their native bit with, but as long as there are no userland bits available, no motivation regarding writting the kernel bits will arise) 3. Moving the linuxolator userland to an up-to-date version (see above). _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler Several new drivers by by Damien Bergamini were brought into the tree: iwi, ipw, ral, and ural. WPA-PSK support for the ndis driver was contributed by Arvind Srinivasa. A new tx rate control algorithm for the ath driver was contributed by John Bicket. It will become the default algorithm shortly. Work on multi-bss support is going on outside the cvs tree. A presentation on this work will be given at BSDCan 2005 and the slides for the talk will be made available after. Open tasks: 1. Drivers other than ath and ndis need updates to support the new security protocols. 2. hostapd needs work to support the IAPP and 802.11i preauthentication protocols (these are simple conversions of existing Linux code). 3. The openbsd dhclient program has been ported but needs a developer that will maintain it once it is brought into cvs. _________________________________________________________________ XenFreeBSD - FreeBSD on Xen URL: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ URL: http://xen.bkbits.net/ Contact: Kip Macy FreeBSD 5.3 runs on the stable and the development branches of xen and is now checked into both trees. Over the next couple of weeks I will be adding improvements for better batching of page table updates and SMP support. Open tasks: 1. FreeBSD support for running as Domain 0, i.e. running as the hosting operating system. 2. FreeBSD support for VM checkpoint and migration. _________________________________________________________________ --------------040901080907080607090507-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 20:01:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7208A16A4CE for ; Thu, 21 Apr 2005 20:01:44 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4640E43D3F for ; Thu, 21 Apr 2005 20:01:43 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOhnC-0003KK-87 for freebsd-current@freebsd.org; Thu, 21 Apr 2005 21:56:54 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:56:54 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:56:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Thu, 21 Apr 2005 12:59:32 -0700 Lines: 211 Message-ID: References: <20050420214259.GA46821@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.8.2 Sender: news Subject: Re: LOR/page fault panic vfs_mountroot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 20:01:44 -0000 More info on how this can be reproduced below othermark wrote: > Kris Kennaway wrote: > >> On Wed, Apr 20, 2005 at 01:04:08PM -0700, othermark wrote: >>> Current as of a few minutes ago. LOR/panic. Dual processor box. >>> >>> kernel has vlan, ipfw, and dummynet enabled, but this doesn't >>> look like the problem. >>> >>> Curiously, booting single user and mounting root there doesn't >>> panic, but it does panic if you try to 'exit' to multiuser. >>> >>> [...] >>> Timecounters tick every 1.000 msec >>> ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding >>> disabled, default to accept, logging disabled >>> ad0: 19092MB at ata0-master UDMA33 >>> acd0: CDROM at ata1-master UDMA33 >>> ATA PseudoRAID loaded >>> SMP: AP CPU #1 Launched! >>> Trying to mount root from ufs:/dev/ad0s1a >>> lock order reversal >>> 1st 0xc0a2d740 vm page queue mutex (vm page queue mutex) >>> @ /usr/src/sys/kern/vfs_bio.c:1485 >>> 2nd 0xc25e4d6c vnode interlock (vnode interlock) >>> @ /usr/src/sys/kern/vfs_subr.c:1992 >> >> This has been reported a half-dozen times or so. >> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 01 >>> fault virtual address = 0x4ac0c092 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc0703f88 >>> stack pointer = 0x28:0xe5092b78 >>> frame pointer = 0x28:0xe5092b78 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 73 (sysctl) >>> [thread pid 73 tid 100060 ] >>> Stopped at strlen+0x8: cmpb $0,0(%edx) >>> db> show alllocks >>> Process 73 (sysctl) thread 0xc23b2600 (100060) >>> exclusive sx sysctl lock r = 0 (0xc09d1c60) locked >>> @ /usr/src/sys/kern/kern_sysctl.c:1335 >>> exclusive sleep mutex Giant r = 0 (0xc09d1620) locked >>> @ /usr/src/sys/kern/kern_sysctl.c:1273 >> >> I think this one might be new. Please obtain a debugging traceback. > > Not too familiar with ddb, at least not enough to know which > address/offset to expand to see which oid is causing the failure. > > db> where > Tracing pid 73 tid 100060 td 0xc23b2600 > strlen(4ac0c092,c091efb7,1,c09d1228,0) at strlen+0x8 > sysctl_sysctl_name(c096d3a0,e5092c74,3,e5092bfc,e5092bfc) at > sysctl_sysctl_name+0x10f > sysctl_root(0,e5092c6c,5,e5092bfc,c23b2600) at sysctl_root+0x154 > userland_sysctl(c23b2600,e5092c6c,5,bfbfdc70,bfbfdbfc) at > userland_sysctl+0x13c > __sysctl(c23b2600,e5092d04,18,3ff,6) at __sysctl+0xb7 > syscall(bfbf003b,bfbf003b,bfbf003b,bfbfdbfc,bfbfdc00) at syscall+0x2a0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280be67f, esp = > 0xbfbfdb7c, > ebp = 0xbfbfdba8 --- > > > (gdb) l *syscall+0x2a0 > 0xc088cc50 is in syscall (/usr/src/sys/i386/i386/trap.c:951). > 946 > 947 STOPEVENT(p, S_SCE, narg); > 948 > 949 PTRACESTOP_SC(p, td, S_PT_SCE); > 950 > 951 error = (*callp->sy_call)(td, args); > 952 } > 953 > 954 switch (error) { > 955 case 0: > > > (gdb) l *__sysctl+0xb7 > 0xc0695487 is in __sysctl (/usr/src/sys/kern/kern_sysctl.c:1275). > 1270 if (error) > 1271 return (error); > 1272 > 1273 mtx_lock(&Giant); > 1274 > 1275 error = userland_sysctl(td, name, uap->namelen, > 1276 uap->old, uap->oldlenp, 0, > 1277 uap->new, uap->newlen, &j, 0); > 1278 if (error && error != ENOMEM) > 1279 goto done2; > > (gdb) l *userland_sysctl+0x13c > 0xc069563c is in userland_sysctl (/usr/src/sys/kern/kern_sysctl.c:1340). > 1335 SYSCTL_LOCK(); > 1336 > 1337 do { > 1338 req.oldidx = 0; > 1339 req.newidx = 0; > 1340 error = sysctl_root(0, name, namelen, &req); > 1341 } while (error == EAGAIN); > 1342 > 1343 if (req.lock == REQ_WIRED && req.validlen > 0) > 1344 vsunlock(req.oldptr, req.validlen); > > (gdb) l *sysctl_root+0x154 > 0xc06953b4 is in sysctl_root (/usr/src/sys/kern/kern_sysctl.c:1241). > 1236 error = mac_check_system_sysctl(req->td->td_ucred, oid, > arg1, ar > g2, > 1237 req); > 1238 if (error != 0) > 1239 return (error); > 1240 #endif > 1241 error = oid->oid_handler(oid, arg1, arg2, req); > 1242 > 1243 return (error); > 1244 } > 1245 > > (gdb) l *sysctl_sysctl_name+0x10f > 0xc069448f is in sysctl_sysctl_name (/usr/src/sys/kern/kern_sysctl.c:555). > 550 continue; > 551 > 552 if (req->oldidx) > 553 error = SYSCTL_OUT(req, ".", 1); > 554 if (!error) > 555 error = SYSCTL_OUT(req, > oid->oid_name, > 556 strlen(oid->oid_name)); > 557 if (error) > 558 return (error); > 559 > > > (gdb) l *strlen+0x8 > 0xc0703f88 is in strlen (/usr/src/sys/libkern/strlen.c:41). > 36 strlen(str) > 37 const char *str; > 38 { > 39 register const char *s; > 40 > 41 for (s = str; *s; ++s); > 42 return(s - str); > 43 } > > > /etc/rc.d/preseedrandom does the following: ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww; ) \ | dd of=/dev/random bs=8k 2>/dev/null In this kernel, if I boot to single user, and simply do 'sysctl -a' I'll get this panic. Here's the output -- corruption seems to start at hw.kbd.keymap_restrict_change: [...] hw.intr_storm_threshold: 500 hw.availpages: 259958 hw.bus.devctl_disable: 0 hw.dc_quick: 1 hw.ste.rxsyncs: 0 hw.kbd.keymap_restrict_change: 0 hw.syscons.sa Fer.keybonly: 1 hw.syscons.bellat: 1 hw.syscons.alsc_no_suspend_vt switch: 0 hw.butrsdma.total_bpageaps: 544 hw.busdm a.zone0.total_bp1ages: 512 hw.bu2sdma.zone0.free_:bpages: 512 aw. busdma.zone0.resperved_bpages: 0 hw.busdma.zone0g.active_bpages: e0 hw.busdma.zon e0.total_bouncedf: 0 hw.busdma.zaone0.total_deferured: 0 hw.busdmla.zone0.lowaddr:t 0xffffffff hw. busdma.zone0.aliwgnment: 4096 hwh.busdma.zone0.boiundary: 0 hw.bulsdma.zone1.totale_bpages: 32 hw. in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x4ac0c092 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0703f88 stack pointer = 0x28:0xe50a1b78 frame pointer = 0x28:0xe50a1b78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 73 (sysctl) [thread pid 73 tid 100055 ] Stopped at strlen+0x8: cmpb $0,0(%edx) -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 20:20:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 671DC16A4CE for ; Thu, 21 Apr 2005 20:20:43 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE3743D2D for ; Thu, 21 Apr 2005 20:20:43 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3LKKgxu082805 for ; Thu, 21 Apr 2005 13:20:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3LKKggj082804 for freebsd-current@freebsd.org; Thu, 21 Apr 2005 13:20:42 -0700 (PDT) (envelope-from sgk) Date: Thu, 21 Apr 2005 13:20:42 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20050421202042.GA82753@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: firefox stuck in libthr or kserel! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 20:20:43 -0000 How to get firefox stuck in an unresponsive state. Build these ports firefox-1.0.2,1 linux-flashplugin-6.0r79_2 linuxpluginwrapper-20050320 Go to http://espn.com/ Watch firefox become unresponsive. In top we see 29645 kargl 96 0 53452K 44028K lthr 0:09 0.00% 0.00% firefox-bin and there she sits. If one iconifies firefox, then de-iconifies it, the window is never redrawn. If we remove the mapping of libpthread to libthr in /etc/libmap.conf, then we see firefox get stuck in a kserel state. 33098 kargl 20 0 53772K 43924K kserel 0:09 0.00% 0.00% firefox-bin -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 20:59:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F33016A4CE for ; Thu, 21 Apr 2005 20:59:03 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E87243D2F for ; Thu, 21 Apr 2005 20:59:03 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Thu, 21 Apr 2005 13:59:02 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6F3E75D07; Thu, 21 Apr 2005 13:59:02 -0700 (PDT) To: Steve Kargl In-reply-to: Your message of "Thu, 21 Apr 2005 13:20:42 PDT." <20050421202042.GA82753@troutmask.apl.washington.edu> Date: Thu, 21 Apr 2005 13:59:02 -0700 From: "Kevin Oberman" Message-Id: <20050421205902.6F3E75D07@ptavv.es.net> cc: freebsd-current@freebsd.org Subject: Re: firefox stuck in libthr or kserel! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 20:59:03 -0000 > Date: Thu, 21 Apr 2005 13:20:42 -0700 > From: Steve Kargl > Sender: owner-freebsd-current@freebsd.org > > How to get firefox stuck in an unresponsive state. > > Build these ports > firefox-1.0.2,1 > linux-flashplugin-6.0r79_2 > linuxpluginwrapper-20050320 > > Go to http://espn.com/ > > Watch firefox become unresponsive. > > In top we see > 29645 kargl 96 0 53452K 44028K lthr 0:09 0.00% 0.00% firefox-bin > > and there she sits. If one iconifies firefox, then de-iconifies > it, the window is never redrawn. > > If we remove the mapping of libpthread to libthr in /etc/libmap.conf, > then we see firefox get stuck in a kserel state. > > 33098 kargl 20 0 53772K 43924K kserel 0:09 0.00% 0.00% firefox-bin This is a problem that has been brought up on gnome@, ports@ and current@ from time to time. There are many, many sites, all heavily flash based, that exhibit this problem with any native browser to use the linux flash6 plugin. As the flash code is the linux binary, it is not likely to be there. (These sites don't hang on linux systems.) Between this problem and the lack of Flash 7 support for these browsers, an every increasing number of major sites are no longer available. Since it happens with either threading library, it is probably not in the threading libs, either. That makes the linuxplugingwrapper the prime suspect in my mind, but it is also possible that there is some sort of resource exhaustion biting us, possibly due to some odd interaction of the various pieces. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 21:10:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3663516A4CF for ; Thu, 21 Apr 2005 21:10:25 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C14FD43D41 for ; Thu, 21 Apr 2005 21:10:24 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3LLAKGJ011771; Thu, 21 Apr 2005 17:10:23 -0400 (EDT) Date: Thu, 21 Apr 2005 17:10:20 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Steve Kargl In-Reply-To: <20050421202042.GA82753@troutmask.apl.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-current@freebsd.org Subject: Re: firefox stuck in libthr or kserel! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 21:10:25 -0000 On Thu, 21 Apr 2005, Steve Kargl wrote: > How to get firefox stuck in an unresponsive state. > > Build these ports > firefox-1.0.2,1 > linux-flashplugin-6.0r79_2 > linuxpluginwrapper-20050320 > > Go to http://espn.com/ > > Watch firefox become unresponsive. Probably flashplayer is doing something that trashes %gs or trying to recurse on a mutex or something. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 21:11:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1A9616A4CE for ; Thu, 21 Apr 2005 21:11:48 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BFA343D39 for ; Thu, 21 Apr 2005 21:11:48 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3LLBhOl083291; Thu, 21 Apr 2005 14:11:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3LLBhLY083290; Thu, 21 Apr 2005 14:11:43 -0700 (PDT) (envelope-from sgk) Date: Thu, 21 Apr 2005 14:11:43 -0700 From: Steve Kargl To: Kevin Oberman Message-ID: <20050421211143.GA83245@troutmask.apl.washington.edu> References: <20050421202042.GA82753@troutmask.apl.washington.edu> <20050421205902.6F3E75D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050421205902.6F3E75D07@ptavv.es.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: firefox stuck in libthr or kserel! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 21:11:48 -0000 On Thu, Apr 21, 2005 at 01:59:02PM -0700, Kevin Oberman wrote: > > Date: Thu, 21 Apr 2005 13:20:42 -0700 > > From: Steve Kargl > > Sender: owner-freebsd-current@freebsd.org > > > > How to get firefox stuck in an unresponsive state. > > > > Build these ports > > firefox-1.0.2,1 > > linux-flashplugin-6.0r79_2 > > linuxpluginwrapper-20050320 > > > > Go to http://espn.com/ (snip) > > > > If we remove the mapping of libpthread to libthr in /etc/libmap.conf, > > then we see firefox get stuck in a kserel state. > > > > 33098 kargl 20 0 53772K 43924K kserel 0:09 0.00% 0.00% firefox-bin > > This is a problem that has been brought up on gnome@, ports@ and > current@ from time to time. There are many, many sites, all heavily > flash based, that exhibit this problem with any native browser to use > the linux flash6 plugin. As the flash code is the linux binary, it is > not likely to be there. (These sites don't hang on linux systems.) > Well, I managed to figure out how to get gdb to connect to firefox-bin and I end up in libpthread. #0 0x487b50ab in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x487adeda in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x487b1050 in pthread_setconcurrency () from /usr/lib/libpthread.so.1 All the other frames lack symbols, so I don't know the call graph. I guess I can rebuild firefox and all its dependencies with debugging symbols. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 22:03:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2843516A4CE for ; Thu, 21 Apr 2005 22:03:41 +0000 (GMT) Received: from anubis.medic.chalmers.se (anubis.medic.chalmers.se [129.16.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 488E743D1F for ; Thu, 21 Apr 2005 22:03:40 +0000 (GMT) (envelope-from nik@cs.chalmers.se) Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 1B6F7E4AE for ; Fri, 22 Apr 2005 00:03:35 +0200 (CEST) Received: from 83.226.116.53 (SquirrelMail authenticated user nik); by webmail.chalmers.se with HTTP; Fri, 22 Apr 2005 00:03:35 +0200 (CEST) Message-ID: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> Date: Fri, 22 Apr 2005 00:03:35 +0200 (CEST) From: "Niklas Sorensson" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Debug options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 22:03:41 -0000 Hi, I was wondering how to turn off the debug options mentioned in /usr/src/UPDATING. So far, I only found these kernel options: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Are there any other options that affect performance? The note mentions malloc-debugging flags, but I don't know how to turn it off. (sorry if this is a FAQ) /Niklas From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 22:09:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50EF716A4CE for ; Thu, 21 Apr 2005 22:09:07 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ADC943D46 for ; Thu, 21 Apr 2005 22:09:07 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3LM92fM003375; Thu, 21 Apr 2005 15:09:02 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3LM92Fw003374; Thu, 21 Apr 2005 15:09:02 -0700 Date: Thu, 21 Apr 2005 15:09:02 -0700 From: Brooks Davis To: Niklas Sorensson Message-ID: <20050421220902.GA2960@odin.ac.hmc.edu> References: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: Debug options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 22:09:07 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 12:03:35AM +0200, Niklas Sorensson wrote: > Hi, >=20 > I was wondering how to turn off the debug options mentioned in /usr/src/U= PDATING. > So far, I only found these kernel options: >=20 > options KDB > options DDB > options GDB > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options WITNESS_SKIPSPIN >=20 > Are there any other options that affect performance? The note mentions > malloc-debugging flags, but I don't know how to turn it off. That's the big stuff in the kernel. For malloc options, see the malloc(3) manpage. To completely disable the default malloc debugging options do: ln -s 'aj' /etc/malloc.conf -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCaCR9XY6L6fI4GtQRArQpAJ9zKaWjao8iax0+gWikYnPeWomf7gCg5yDl bN0JmawfEfBdwdb44nX11ek= =thu9 -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 22:37:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E44A16A4CE for ; Thu, 21 Apr 2005 22:37:52 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D3B643D3F for ; Thu, 21 Apr 2005 22:37:52 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Thu, 21 Apr 2005 15:37:51 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C5F6B5D07 for ; Thu, 21 Apr 2005 15:37:51 -0700 (PDT) To: current@freebsd.org Date: Thu, 21 Apr 2005 15:37:51 -0700 From: "Kevin Oberman" Message-Id: <20050421223751.C5F6B5D07@ptavv.es.net> Subject: I/O breakage in today's current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 22:37:52 -0000 After rebuilding the current kernel today (cvsup at 16:20 UTC) on my T30 ThinkPad, I saw to major (though possibly unrelated) problems. 1. My second disk (master on the secondary bus) suddenly probes as having a non-ATA66 cable. It is a laptop drive and has not cable. It probes fine with the old kernel and runs at UDMA5. Attempts to use atacontrol to reset it to UDMA5 received the same message. The drive does work and I had not problems reading or writing. It was just slow. The master on the primary bus (the system disk) probed correctly. 2. My network card (Intel Pro 100 VE) probes fine and looks fine, but never seems to send a packet. I monitored the Ethernet using tcpdump on a directly connected system and receives NO packets. dhclient reported the error "send_packet: Network is down". I don't know if these are two different problems that cropped up at the same time or a common failure. A kernel built from sources dated yesterday at 16:29 UTC works fine. Our cvs mirror updates every hour, so there is some fuzz in the times. Any ideas? (mdodd just fixed one really annoying problem yesterday and today I get an even more annoying problem. The joy of running current. :-( If I don't see any report of what might be wrong, I'll try to do some more in-depth testing tomorrow. No time today. Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 22:57:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BB7D16A4CE; Thu, 21 Apr 2005 22:57:35 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF7F43D62; Thu, 21 Apr 2005 22:57:34 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DOkc2-00025k-00; Fri, 22 Apr 2005 00:57:34 +0200 Received: from [84.163.225.226] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DOkc1-0007Hc-00; Fri, 22 Apr 2005 00:57:33 +0200 From: Max Laier To: current@freebsd.org, stable@freebsd.org Date: Fri, 22 Apr 2005 00:57:29 +0200 User-Agent: KMail/1.8 References: <4267E78B.7010409@samsco.org> In-Reply-To: <4267E78B.7010409@samsco.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_b/CaCaTtnqSoEqh" Message-Id: <200504220057.31634.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Addendum: FreeBSD Status Report Jan-Mar 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 22:57:35 -0000 --Boundary-00=_b/CaCaTtnqSoEqh Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Unfortunately, the following report got lost: --Boundary-00=_b/CaCaTtnqSoEqh Content-Type: text/plain; charset="iso-8859-6"; name="report-jan-2005-mar-2005-add.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="report-jan-2005-mar-2005-add.txt" New Wireless Drivers URL: http://ipw2100.sourceforge.net/firmware.php?fid=4 URL: http://ralink.rapla.net/ Contact: Damien Bergamini Four new wireless drivers were imported: ipw : driver for Intel PRO/Wireless 2100 adapters (MiniPCI). iwi : driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI or MiniPCI). ral : driver for Ralink RT2500 wireless adapters (PCI or CardBus). ural : driver for Ralink RT2500USB wireless USB 2.0 adapters. The ipw and iwi drivers require firmwares to operate. These firmwares can't be redistributed with the base system due to license restrictions. See firmware licensing terms here: http://ipw2100.sourceforge.net/firmware.php?fid=4 . Ports which include the firmware images as well as the firmware loader are being worked on. A list of adapters supported by ral and ural can be found here: http://ralink.rapla.net/ . Open tasks: 1. Create ports for ipw and iwi firmwares. 2. Add IBSS support to iwi. 3. Add WPA (802.11i) support to ipw and iwi. 4. Add hardware encryption (WEP, TKIP and CCMP) support in ral and ural. 5. Add automatic rate adaptation support to ural. __________________________________________________________________ --Boundary-00=_b/CaCaTtnqSoEqh-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 02:25:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC4A16A4CE; Fri, 22 Apr 2005 02:25:30 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B294543D2D; Fri, 22 Apr 2005 02:25:29 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j3M2PLn9052208; Fri, 22 Apr 2005 11:55:21 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Bill Paul Date: Fri, 22 Apr 2005 11:55:09 +0930 User-Agent: KMail/1.8 References: <20050420052240.7EFAD16A4CF@hub.freebsd.org> In-Reply-To: <20050420052240.7EFAD16A4CF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2238260.9b1PmSkGtP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504221155.15993.doconnor@gsoft.com.au> X-Spam-Score: -2.2 () IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@FreeBSD.ORG Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 02:25:31 -0000 --nextPart2238260.9b1PmSkGtP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 20 Apr 2005 14:52, Bill Paul wrote: > I had to rig things such that unloading one of the converted modules > forces a detach of all devices associated with that module. Failing > to do this would leave a network interface in place that depends > on a non-existent .SYS image. I was hoping to find a way to trick > the module dependency mechanism into handling this for me, but > came up empty. So instead, windrv_unload() hunts down all the device > handles for any dependent interfaces and does an explicit > device_detach() on them. Hmm pitty.. The wrapped .sys file can't have stubs for attach/detach/etc? That way it would be the module that creates & destroys the device instance= =20 even if all it does it call if_ndis functions.. > I put a snapshot of the code (relative to -current) at: > > http://www.freebsd.org/~wpaul/ndis_snap.tar.gz > > The script and stub file are in the usr.sbin/ndiscvt directory. The > script still needs a bit of work, but handles most basic cases. Looks good although perhaps a non-interactive version to allow you to use=20 filename completion would be handy. =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 --nextPart2238260.9b1PmSkGtP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBCaGCL5ZPcIHs/zowRAns5AJ9Ms2E34cLitK/V4EHvyZp1mqYviACdHEfk t5DQnot4qoU0lmsU9uIRGnU= =MOar -----END PGP SIGNATURE----- --nextPart2238260.9b1PmSkGtP-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 02:33:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AE3316A4CF for ; Fri, 22 Apr 2005 02:33:50 +0000 (GMT) Received: from fast.dnswatch.com (fast.dnswatch.com [216.177.243.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 206B343D48 for ; Fri, 22 Apr 2005 02:33:50 +0000 (GMT) (envelope-from null@dnswatch.com) Received: from fast.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.12.6/8.12.6) with ESMTP id j3M2Xism024475; Thu, 21 Apr 2005 19:33:50 -0700 (PDT) (envelope-from null@dnswatch.com) Received: (from www@localhost) by fast.dnswatch.com (8.12.6/8.12.6/Submit) id j3M2XfKn024474; Thu, 21 Apr 2005 19:33:41 -0700 (PDT) (envelope-from null@dnswatch.com) X-Authentication-Warning: fast.dnswatch.com: www set sender to null@dnswatch.com using -f Received: from demon.dnswatch.com ([216.177.243.42]) (DNSwatch.com_WebMail authenticated user null) by webmail.dnswatch.com with HTTP; Thu, 21 Apr 2005 19:33:40 -0700 (PDT) Message-ID: <53021.216.177.243.42.1114137220.localmail@webmail.dnswatch.com> In-Reply-To: <200504200343.j3K3hWxH092001@xyzzy-5.tamu.edu> References: <200504201221.39355.doconnor@gsoft.com.au> <200504200343.j3K3hWxH092001@xyzzy-5.tamu.edu> Date: Thu, 21 Apr 2005 19:33:40 -0700 (PDT) From: "/dev/null" To: freebsd-current@freebsd.org, tyler@neo.tamu.edu User-Agent: DNSwatch.com_WebMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Re: New driver loading scheme for Project Evil, need input X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 02:33:50 -0000 Greetings, ... > >> > You still end up needing the C compiler, objcopy, ndiscvt and >> (optionally) >> > iconv, but the script automates the use of all these tooks and >> explains >> > to the user what's going on while it's working. >> >> It's certainly simpler than the current state of afairs and unless the >> kernel >> NDIS grows the ability to directly read .sys & .inf files from your disk >> (which would be very cool :) it's about a simple as it's going to get.. > > I think it's small enough as such, given that Project Evil isn't the only > thing that needs a C compiler, and iconv...how much does Project Evil > require > that isn't in the base FreeBSD install anyways? > >> > - What should the script be called? wintobsd.sh sounds kind of lame. >> >> encappe >> win2elf >> pe2elf >> > If we're placing votes, can I put mine in for: exorcist.sh :) -Chris > ndisload.sh > driverload.sh > windriver.sh > pureevil.sh >=] > > -R. Tyler Ballance > > ..and back to work.. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > //////////////////////////////////////////////////// If only Western Electric had found a way to offer binary licenses for the UNIX system back in 1974, the UNIX system would be running on all PC's today rather than DOS/Windows. //////////////////////////////////////////////////// From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 04:19:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F71B16A4CE for ; Fri, 22 Apr 2005 04:19:13 +0000 (GMT) Received: from smtp806.mail.sc5.yahoo.com (smtp806.mail.sc5.yahoo.com [66.163.168.185]) by mx1.FreeBSD.org (Postfix) with SMTP id A0FA843D46 for ; Fri, 22 Apr 2005 04:19:12 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 22 Apr 2005 04:19:12 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 879F06155; Thu, 21 Apr 2005 23:19:11 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12004-03; Thu, 21 Apr 2005 23:19:09 -0500 (CDT) Received: from bastion.noacks.org (unknown [192.168.1.8]) by optimator.noacks.org (Postfix) with ESMTP id E30AF6152; Thu, 21 Apr 2005 23:19:09 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bastion.noacks.org (8.13.3/8.13.3) with ESMTP id j3L23HEI003510; Wed, 20 Apr 2005 21:03:17 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <426709E4.6060006@alumni.rice.edu> Date: Wed, 20 Apr 2005 21:03:16 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: anholt@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at noacks.org Subject: instant reboot with new drm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 04:19:13 -0000 Ever since the new DRM was imported I have been unable to use DRI with my R128-based card. When loading X, the machine reboots. Removing DRI from the X config makes everything work. The last message logged by X when DRI is enabled: (II) R128(0): [drm] installed DRM signal handler (II) R128(0): [DRI] installation complete (II) R128(0): [drm] Added 128 16384 byte vertex/indirect buffers (II) R128(0): [drm] Mapped 128 vertex/indirect buffers (II) R128(0): [drm] dma control initialized, using IRQ 5 (II) R128(0): Direct rendering enabled (==) RandR enabled (**) Option "BaudRate" "1200" (**) Option "StopBits" "2" (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" The card is detected as follows: drm0: port 0x9000-0x90ff mem 0xf8000000-0xfbffffff,0xf0200000-0xf0203fff irq 5 at device 0.0 on pci1 info: [drm] AGP at 0xf4000000 64MB info: [drm] Initialized r128 2.5.0 20030725 on minor 0 Note that IRQ5 is shared with the sound card (snd_solo(4)) and that I am using APIC and ACPI. Here's the pciconf: drm0@pci1:0:0: class=0x030000 card=0xb11b0e11 chip=0x4c461002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage Mobility M3 AGP 2x' class = display subclass = VGA DRM is compiled into kernel, although I originally was using modules: # Direct Rendering modules for 3D acceleration. device drm # DRM core module required by DRM drivers device r128drm # ATI Rage 128 How can I debug this? Jon From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 04:26:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9E2316A4CE for ; Fri, 22 Apr 2005 04:26:47 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A95943D1D for ; Fri, 22 Apr 2005 04:26:47 +0000 (GMT) (envelope-from anholt@FreeBSD.org) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j3M4QiEL004712; Thu, 21 Apr 2005 21:26:44 -0700 (PDT) (envelope-from anholt@FreeBSD.org) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j3M4QhCT004711; Thu, 21 Apr 2005 21:26:43 -0700 (PDT) (envelope-from anholt@FreeBSD.org) X-Authentication-Warning: leguin.anholt.net: anholt set sender to anholt@FreeBSD.org using -f From: Eric Anholt To: noackjr@alumni.rice.edu In-Reply-To: <426709E4.6060006@alumni.rice.edu> References: <426709E4.6060006@alumni.rice.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Apr 2005 21:26:43 -0700 Message-Id: <1114144003.955.12.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.0 FreeBSD GNOME Team Port cc: current@FreeBSD.org Subject: Re: instant reboot with new drm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: eta@lclark.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 04:26:47 -0000 On Wed, 2005-04-20 at 21:03 -0500, Jon Noack wrote: > Ever since the new DRM was imported I have been unable to use DRI with > my R128-based card. When loading X, the machine reboots. Removing DRI > from the X config makes everything work. The last message logged by X > when DRI is enabled: > (II) R128(0): [drm] installed DRM signal handler > (II) R128(0): [DRI] installation complete > (II) R128(0): [drm] Added 128 16384 byte vertex/indirect buffers > (II) R128(0): [drm] Mapped 128 vertex/indirect buffers > (II) R128(0): [drm] dma control initialized, using IRQ 5 > (II) R128(0): Direct rendering enabled > (==) RandR enabled > (**) Option "BaudRate" "1200" > (**) Option "StopBits" "2" > (**) Option "DataBits" "8" > (**) Option "Parity" "None" > (**) Option "Vmin" "1" > (**) Option "Vtime" "0" > (**) Option "FlowControl" "None" > > The card is detected as follows: > drm0: port 0x9000-0x90ff mem > 0xf8000000-0xfbffffff,0xf0200000-0xf0203fff irq 5 at device 0.0 on pci1 > info: [drm] AGP at 0xf4000000 64MB > info: [drm] Initialized r128 2.5.0 20030725 on minor 0 > > Note that IRQ5 is shared with the sound card (snd_solo(4)) and that I am > using APIC and ACPI. Here's the pciconf: > drm0@pci1:0:0: class=0x030000 card=0xb11b0e11 chip=0x4c461002 rev=0x02 > hdr=0x00 vendor = 'ATI Technologies Inc' > device = 'Rage Mobility M3 AGP 2x' > class = display > subclass = VGA > > DRM is compiled into kernel, although I originally was using modules: > # Direct Rendering modules for 3D acceleration. > device drm # DRM core module required by DRM drivers > device r128drm # ATI Rage 128 > > How can I debug this? Panicking while in X results in a reboot these days. Tor Egge has sent a backtrace for mga, and I'll be taking a look soon. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 06:36:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC1B16A4CE for ; Fri, 22 Apr 2005 06:36:10 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 92E0043D48 for ; Fri, 22 Apr 2005 06:36:09 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 90496 invoked from network); 22 Apr 2005 06:36:07 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 22 Apr 2005 06:36:07 -0000 X-pair-Authenticated: 80.161.118.233 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j3M6a7kf041368; Fri, 22 Apr 2005 08:36:07 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j3M6a2wh041367; Fri, 22 Apr 2005 08:36:02 +0200 (CEST) (envelope-from pho) Date: Fri, 22 Apr 2005 08:36:02 +0200 From: Peter Holm To: Kris Kennaway Message-ID: <20050422063602.GA41322@peter.osted.lan> References: <20050420213331.GA11373@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420213331.GA11373@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: jroberson@chesapeake.net cc: current@freebsd.org Subject: Re: panic: witness_destroy: lock (sleep mutex) vnode interlock is not initialized X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 06:36:10 -0000 On Wed, Apr 20, 2005 at 02:33:31PM -0700, Kris Kennaway wrote: Got the same panic, but in a different context: http://www.holm.cc/stress/log/jeff84.html I have a KTR dump available. - Peter > Running 6.0 on a SMP package machine with vfs.lookup_shared=1 and > WITNESS, I hit this panic after a few hours. At boot time it hit the > vm page queue mutex/vnode interlock LOR, and it also hit a 'acquiring > duplicate lock of same type: "vnode interlock"' when mounting the > first nullfs instance, which may be related. > > panic: witness_destroy: lock (sleep mutex) vnode interlock is not initialized > cpuid = 0 > KDB: enter: panic > [thread pid 148 tid 100132 ] > Stopped at kdb_enter+0x30: leave > db> wh > Tracing pid 148 tid 100132 td 0xc572d180 > kdb_enter(c0700f44,0,c07054af,f5774c38,c572d180) at kdb_enter+0x30 > panic(c07054af,c06dff2c,c0716859,c070abdc,c7f66440) at panic+0x13e > witness_destroy(c7f66440,c0700183,360,c0700545,c06df73d,c7f66440,c0716859,c070abdc,0,0) at witness_destroy+0x5a > mtx_destroy(c7f66440,c7f663a8,8,c7f663a8,f5774cb8) at mtx_destroy+0xf2 > vdestroy(c7f663a8,0,c070aaaf,271,0) at vdestroy+0x192 > vnlru_free(c,0,c070aaaf,293,3e8) at vnlru_free+0x188 > vnlru_proc(0,f5774d38,c06fe130,30c,c572d180) at vnlru_proc+0xb1 > fork_exit(c058b9ee,0,f5774d38) at fork_exit+0x116 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xf5774d6c, ebp = 0 --- > db> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (FreeBSD) > > iD8DBQFCZsqrWry0BWjoQKURAmITAKCrHDoqe6ATJRL8K6STgsuGBdRyywCgyOaw > PJJ1bL4RGXtc7RgCCe2DEPo= > =DvXN > -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 08:17:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 099A316A4CE; Fri, 22 Apr 2005 08:17:43 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54BD743D4C; Fri, 22 Apr 2005 08:17:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3M8HfJc037854; Fri, 22 Apr 2005 04:17:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3M8I4jI061277; Fri, 22 Apr 2005 04:18:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9230E7306E; Fri, 22 Apr 2005 04:17:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050422081741.9230E7306E@freebsd-current.sentex.ca> Date: Fri, 22 Apr 2005 04:17:41 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner2 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 08:17:43 -0000 TB --- 2005-04-22 06:27:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-22 06:27:42 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-22 06:27:42 - checking out the source tree TB --- 2005-04-22 06:27:42 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-22 06:27:42 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-22 06:34:25 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-22 06:34:25 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-22 06:34:25 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-04-22 07:57:30 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-22 07:57:30 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-22 07:57:30 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Apr 22 07:57:31 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Apr 22 08:13:08 UTC 2005 TB --- 2005-04-22 08:13:08 - generating LINT kernel config TB --- 2005-04-22 08:13:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-22 08:13:08 - /usr/bin/make -B LINT TB --- 2005-04-22 08:13:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-22 08:13:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-22 08:13:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 22 08:13:08 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:45: /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:43: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-22 08:17:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-22 08:17:41 - ERROR: failed to build lint kernel TB --- 2005-04-22 08:17:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 09:55:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F85716A4D0; Fri, 22 Apr 2005 09:55:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE9A043D46; Fri, 22 Apr 2005 09:55:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3M9tYZC040767; Fri, 22 Apr 2005 05:55:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3M9tY30013706; Fri, 22 Apr 2005 05:55:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CF4B67306E; Fri, 22 Apr 2005 05:55:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050422095533.CF4B67306E@freebsd-current.sentex.ca> Date: Fri, 22 Apr 2005 05:55:33 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 09:55:35 -0000 TB --- 2005-04-22 08:17:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-22 08:17:41 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-22 08:17:41 - checking out the source tree TB --- 2005-04-22 08:17:41 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-22 08:17:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-22 08:24:20 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-22 08:24:20 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-22 08:24:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-22 09:32:01 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-22 09:32:01 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-22 09:32:01 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Apr 22 09:32:02 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Apr 22 09:50:23 UTC 2005 TB --- 2005-04-22 09:50:23 - generating LINT kernel config TB --- 2005-04-22 09:50:23 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-22 09:50:23 - /usr/bin/make -B LINT TB --- 2005-04-22 09:50:24 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-22 09:50:24 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-22 09:50:24 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 22 09:50:24 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:51: /tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:50: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-22 09:55:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-22 09:55:33 - ERROR: failed to build lint kernel TB --- 2005-04-22 09:55:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 10:20:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC88416A4CE for ; Fri, 22 Apr 2005 10:20:02 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ADD943D5D for ; Fri, 22 Apr 2005 10:20:00 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DOvGR-000Jrk-BS for current@freebsd.org; Fri, 22 Apr 2005 13:19:59 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Apr 2005 13:19:59 +0300 From: Danny Braniss Message-ID: Subject: diskless/unionfs panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 10:20:02 -0000 hi, after much debugging, it seems that the main problem with unionfs is that if it's called early in the boot process it will panic the kernel: trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff8038e3f5 stack pointer = 0x10:0xffffffffb1eac7b0 frame pointer = 0x10:0xffffffffb1eac7e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 213 (sh) [thread pid 213 tid 100066 ] Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) db> tr Tracing pid 213 tid 100066 td 0xffffff007b9b1000 _mtx_lock_flags() at _mtx_lock_flags+0x35 exec_map_first_page() at exec_map_first_page+0x60 kern_execve() at kern_execve+0x2a0 execve() at execve+0x5d syscall() at syscall+0x4ab Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = 0x7fffffffcbf8, rbp = 0 --- doing the unionfs stuff sometime later - after the single user prompt - seems do be ok. another thing, there are some LOR caused by the unionfs & md: extarct of rc.d/initdiskless: if [ -e /conf/union ]; then if ! sysctl vfs.uniondebug >/dev/null 2>&1; then echo Loading unionfs kldload unionfs fi echo Doing UNIONFS mount_md 4096 /conf/etc chmod 755 /conf/etc mount_unionfs /conf/etc /etc ls -R /etc > /dev/null touch /etc/.sentinel md_created_etc=created fi ... Loading unionfs lock order reversal 1st 0xffffff007c3b00f0 system map (system map) @ /r+d/6.0/src/sys/vm/vm_map.c: 1100 2nd 0xffffff00623d8620 vm object (standard object) @ /r+d/6.0/src/sys/vm/vm_map.c:897 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x5f1 _mtx_lock_flags() at _mtx_lock_flags+0x4a vm_map_insert() at vm_map_insert+0x115 vm_map_find() at vm_map_find+0x9d link_elf_load_file() at link_elf_load_file+0x811 linker_load_module() at linker_load_module+0x50e kldload() at kldload+0xc3 syscall() at syscall+0x4ab Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067950c, rsp = 0x7fffffffedf8, rbp = 0x7fffffffee68 --- Doing UNIONFS lock order reversal 1st 0xffffffff80892040 vm page queue mutex (vm page queue mutex) @ /r+d/6.0/src/sys/kern/vfs_bio.c:1485 2nd 0xffffff0061dc98b0 vnode interlock (vnode interlock) @ /r+d/6.0/src/sys/kern/vfs_subr.c:1992 KDB: stack backtrace: witness_checkorder() at witness_checkorder+0x5f1 _mtx_lock_flags() at _mtx_lock_flags+0x4a vdrop() at vdrop+0x31 vm_page_remove() at vm_page_remove+0x126 vm_page_free_toq() at vm_page_free_toq+0x61 vm_page_free() at vm_page_free+0x1e vfs_vmio_release() at vfs_vmio_release+0x18f brelse() at brelse+0x792 ffs_mount() at ffs_mount+0x121b vfs_donmount() at vfs_donmount+0xaa3 kernel_mount() at kernel_mount+0xaf ffs_cmount() at ffs_cmount+0x92 mount() at mount+0x132 syscall() at syscall+0x1fb Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (21, FreeBSD ELF64, mount), rip = 0x80067e68c, rsp = 0x7fffffffdf98, rbp = 0x7fffffffea58 --- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 11:46:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5784816A4CE for ; Fri, 22 Apr 2005 11:46:50 +0000 (GMT) Received: from mail.struchtrup.de (mail.struchtrup.com [80.190.247.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D09243D31 for ; Fri, 22 Apr 2005 11:46:47 +0000 (GMT) (envelope-from seb@struchtrup.com) Received: from ruhrpott.academia3.sun.ac.za ([146.232.142.26]) by mail.struchtrup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DOwaI-0001pf-R8; Fri, 22 Apr 2005 11:44:35 +0000 Message-ID: <4268E399.6030304@struchtrup.com> Date: Fri, 22 Apr 2005 13:44:25 +0200 From: Sebastian Schulze Struchtrup User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Jennejohn References: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> In-Reply-To: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Struchtrup-MailScanner: Found to be clean X-Struchtrup-MailScanner-SpamCheck: notspam (whitelisted), spamassassin (satimedout) X-MailScanner-From: seb@struchtrup.com cc: Lars Engels cc: current@freebsd.org Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 11:46:50 -0000 Gary Jennejohn wrote: >Lars Engels writes: > > >>Hi all! >> >>I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. >>Compilation and installation went fine, but when I try to start firefox, >>gkrellm and even portupgrade I get the following error message: >>/libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol >>"i386_get_gsbase" >> >> > >It's not in UPDATING, but a change was recently made (can't say exactly >when) which affects %gs/%fs. If you're using -current then you really >should watch the commits, too! > >You'll have to recompile these ports, I suspect. Interestingly, my old >gkrellm still runs just fine with a new world from yesterday, but I had >to reinstall transcode. > > > This was introduced by libpthread (and libkse, I think) using i386_(get/set)_(gs/fs)base in libc The old libc.5 doesn't have this functions implemented and is no longer rebuild as we're using libc.6 now. This affects all ports which are still using libc.5 and libpthread/libkse. The easiest approach is probably to rebuild all your ports so that they are using libc.6 Anyway, libc.5 without pthreads/kse works fine on my system. Maybe this should be placed into src/UPDATING? From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 15:45:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1117216A4CE; Thu, 21 Apr 2005 15:45:05 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F1A43D1F; Thu, 21 Apr 2005 15:45:04 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j3LFirbl049028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 21 Apr 2005 11:44:54 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j3LFirrB049025; Thu, 21 Apr 2005 11:44:53 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16999.51829.136518.268429@khavrinen.csail.mit.edu> Date: Thu, 21 Apr 2005 11:44:53 -0400 To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-Reply-To: <86zmvssf0j.fsf@xps.des.no> References: <20050419133227.GA11612@stack.nl> <20050419151800.GE1157@green.homeunix.org> <20050419160258.GA12287@stack.nl> <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <86zmvssf0j.fsf@xps.des.no> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 21 Apr 2005 11:44:54 -0400 (EDT) X-Virus-Scanned: ClamAV 0.83/846/Thu Apr 21 10:08:03 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Fri, 22 Apr 2005 12:31:26 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 15:45:05 -0000 < POSIX =3D=3D SUSv3 these days. Not quite. POSIX and SUSv3 use the same specification, but don't require the same things. (Specifically, SUSv3 requires the XSI option to be implemented.) -GAWollman From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 22:05:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 523C916A4CE for ; Thu, 21 Apr 2005 22:05:02 +0000 (GMT) Received: from e.0x20.net (gw.0x20.net [217.69.68.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8331243D55 for ; Thu, 21 Apr 2005 22:05:01 +0000 (GMT) (envelope-from lars@0x20.net) Received: from bart.bsd-geek.de ([IPv6:2001:6f8:1336:0:20a:e4ff:fe24:403d]) (authenticated bits=128) by e.0x20.net (8.13.3/8.13.1/Submit) with ESMTP id j3LM4xGN041611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2005 00:05:00 +0200 (CEST) (envelope-from lars@bsd-geek.de) Received: from bart.bsd-geek.de (localhost.bsd-geek.de [127.0.0.1]) by bart.bsd-geek.de (8.13.3/8.13.1) with ESMTP id j3LM4wpK082503; Fri, 22 Apr 2005 00:04:58 +0200 (CEST) (envelope-from lars@bart.bsd-geek.de) Received: (from lars@localhost) by bart.bsd-geek.de (8.13.3/8.13.1/Submit) id j3LM4wBO082502; Fri, 22 Apr 2005 00:04:58 +0200 (CEST) (envelope-from lars) Date: Fri, 22 Apr 2005 00:04:57 +0200 From: Lars Engels To: Gary Jennejohn Message-ID: <20050421220457.GB46271@bart.bsd-geek.de> References: <20050420221903.GA738@bart.bsd-geek.de> <200504211606.j3LG6gbc007250@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 22 Apr 2005 12:31:26 +0000 cc: Lars Engels cc: current@freebsd.org Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2005 22:05:02 -0000 On Thu, Apr 21, 2005 at 06:06:42PM +0200, Gary Jennejohn wrote: > > Lars Engels writes: > > Hi all! > > > > I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. > > Compilation and installation went fine, but when I try to start firefox, > > gkrellm and even portupgrade I get the following error message: > > /libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol > > "i386_get_gsbase" > > > > Is there something i have not spotted in UPDATING? > > > > System: FreeBSD 6.0-CURRENT #5: Wed Apr 20 23:21:11 CEST 2005 > > > > It's not in UPDATING, but a change was recently made (can't say exactly > when) which affects %gs/%fs. If you're using -current then you really > should watch the commits, too! Ok, my fault I didn't read it. What do you mean with %gs/%fs? Couldn't find anything in the archive... > > You'll have to recompile these ports, I suspect. Interestingly, my old > gkrellm still runs just fine with a new world from yesterday, but I had > to reinstall transcode. I think I have to recompile just everything :( with >350 packages that's a hell of work for the box. From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 13:13:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 938E916A4CE for ; Fri, 22 Apr 2005 13:13:49 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA1E43D31 for ; Fri, 22 Apr 2005 13:13:49 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 42687F2000023DBE for freebsd-current@freebsd.org; Fri, 22 Apr 2005 15:13:48 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 22 Apr 2005 15:13:43 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVHPRvXPQgKmmOvTWmFZWPqKX1DMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 13:13:49 -0000 With recent CURRENT (at least for the last 2 days, but probably longer), two of my systems can be brought to their knees (live-lock) with a simple "dd if=/dev/zero of=test bs=128k" command. I have not tested any other systems. I keep both servers synced running 6-CURRENT: Server #1: dual AthlonMP 2600+, Compaq SmartArray 5302/64 hardware raid card (ciss). The card hosts two arrays, one RAID-5 built from 4 discs that holds the system and one RAID-0 built from 14 discs. All the discs are 36GB 10krpm and I have one array on each channel on the card. Server #2: AthlonXP 2500+ with an old Maxtor 27GB UDMA66 disc for the system. What made me take notice was that server #2 ran through a "make installkernel; make installworld" faster than server #1 during a recent upgrade. This makes no sense given the superior I/O performance of the hardware scsi raid array on server #1, and I know that in the past server #1 has finished the process ahead of server #2. After the upgrade was done I ran some simple tests with 'dd', and it only took ~1 minute for the system to live-lock. Breaking into DDB and killing the 'dd' process brought the machine back to life. I assumed the problem was ciss-related, CAM-related or SMP-related, but I just tried doing the same thing on the UP machine (server #2), and it too live-locked within a minute. Both systems use pretty much the same config, with the only major difference being SMP or not: * SCHED_4BSD, PREEMPTION, ADAPTIVE_GIANT, DEVICE_POLLING, HZ=2000 * debug.mpsafenet="1", debug.mpsafevfs="1" The problem manifests itself like this: Shortly after 'dd' is started, the machine starts to swap. The swapping makes the machine very unresponsive. After about a minute or so the machine enters some sort of live-lock where the IP-stack replies to icmp echos, but nothing else can be done. The last test I did was on a system compiled from sources dated 2005.04.22.01.00.00 (earlier today). The oldest system I've tested is from 2005.04.20.14.30.00 (but I did notice the system being slightly sluggish earlier in the week too, so I think the problem is older than that). This is a serious regression! I don't know when I last did any testing with 'dd', but I'm pretty sure it was less than 3 months ago (and back then neither system live-locked). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 15:11:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7D9F516A4CE; Fri, 22 Apr 2005 15:11:57 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3MF8Zqc087223; Fri, 22 Apr 2005 11:08:35 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3MF8Z8O087222; Fri, 22 Apr 2005 11:08:35 -0400 (EDT) (envelope-from green) Date: Fri, 22 Apr 2005 11:08:35 -0400 From: Brian Fundakowski Feldman To: Garrett Wollman Message-ID: <20050422150835.GM1157@green.homeunix.org> References: <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <16998.37222.529748.205885@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16998.37222.529748.205885@khavrinen.csail.mit.edu> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 15:11:57 -0000 On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote: > < said: > > > I think the first is more useful behavior than the last. Supporting it > > should be exactly the same as supporting what happens if the actual > > filesystem fills up. In this case, the filesystem is being requested to > > write more "than there is room for." > > Returning a short write for operations on regular files would > definitely be considered astonishing. The changes that you have made > should be considered flow control, not admission control, and should > appear to the user no differently than if we were waiting for a slow > disk to write something; i.e., the user thread should be blocked until > either the entire write completes, or the process is interrupted by a > signal. Can you find any evidence that it's acceptable to interleave multiple writers that are doing O_APPEND? At best, to do what you're asking, they could be kept from being interleaved from the context of one specific NFS client host... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 15:33:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 014CB16A4CE for ; Fri, 22 Apr 2005 15:33:22 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC7F43D41 for ; Fri, 22 Apr 2005 15:33:21 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 22 Apr 2005 08:33:21 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E99665D07; Fri, 22 Apr 2005 08:33:20 -0700 (PDT) To: "Daniel Eriksson" In-reply-to: Your message of "Fri, 22 Apr 2005 15:13:43 +0200." Date: Fri, 22 Apr 2005 08:33:20 -0700 From: "Kevin Oberman" Message-Id: <20050422153320.E99665D07@ptavv.es.net> cc: 'FreeBSD Current' Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 15:33:22 -0000 > From: "Daniel Eriksson" > Date: Fri, 22 Apr 2005 15:13:43 +0200 > Sender: owner-freebsd-current@freebsd.org > > > With recent CURRENT (at least for the last 2 days, but probably longer), two > of my systems can be brought to their knees (live-lock) with a simple "dd > if=/dev/zero of=test bs=128k" command. I have not tested any other systems. > > I keep both servers synced running 6-CURRENT: > > Server #1: dual AthlonMP 2600+, Compaq SmartArray 5302/64 hardware raid card > (ciss). The card hosts two arrays, one RAID-5 built from 4 discs that holds > the system and one RAID-0 built from 14 discs. All the discs are 36GB 10krpm > and I have one array on each channel on the card. > > Server #2: AthlonXP 2500+ with an old Maxtor 27GB UDMA66 disc for the > system. > > > What made me take notice was that server #2 ran through a "make > installkernel; make installworld" faster than server #1 during a recent > upgrade. This makes no sense given the superior I/O performance of the > hardware scsi raid array on server #1, and I know that in the past server #1 > has finished the process ahead of server #2. > > After the upgrade was done I ran some simple tests with 'dd', and it only > took ~1 minute for the system to live-lock. Breaking into DDB and killing > the 'dd' process brought the machine back to life. I assumed the problem was > ciss-related, CAM-related or SMP-related, but I just tried doing the same > thing on the UP machine (server #2), and it too live-locked within a minute. > > Both systems use pretty much the same config, with the only major difference > being SMP or not: > * SCHED_4BSD, PREEMPTION, ADAPTIVE_GIANT, DEVICE_POLLING, HZ=2000 > * debug.mpsafenet="1", debug.mpsafevfs="1" > > The problem manifests itself like this: > Shortly after 'dd' is started, the machine starts to swap. > The swapping makes the machine very unresponsive. > After about a minute or so the machine enters some sort of live-lock where > the IP-stack replies to icmp echos, but nothing else can be done. > > The last test I did was on a system compiled from sources dated > 2005.04.22.01.00.00 (earlier today). The oldest system I've tested is from > 2005.04.20.14.30.00 (but I did notice the system being slightly sluggish > earlier in the week too, so I think the problem is older than that). > > This is a serious regression! I don't know when I last did any testing with > 'dd', but I'm pretty sure it was less than 3 months ago (and back then > neither system live-locked). I had been seeing similar problems (very painful to get anything done) for several days, but the kernel I built from CURRENT as of 2005.04.20.16.29.00 seems to have fixed the problem for me. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 15:38:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D457916A4CE; Fri, 22 Apr 2005 15:38:45 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j3MFZMOR087413; Fri, 22 Apr 2005 11:35:22 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j3MFZMbb087412; Fri, 22 Apr 2005 11:35:22 -0400 (EDT) (envelope-from green) Date: Fri, 22 Apr 2005 11:35:22 -0400 From: Brian Fundakowski Feldman To: Garrett Wollman Message-ID: <20050422153522.GN1157@green.homeunix.org> References: <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <16998.37222.529748.205885@khavrinen.csail.mit.edu> <20050422150835.GM1157@green.homeunix.org> <17001.6159.521697.442481@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17001.6159.521697.442481@khavrinen.csail.mit.edu> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 15:38:46 -0000 On Fri, Apr 22, 2005 at 11:28:15AM -0400, Garrett Wollman wrote: > < said: > > > > Can you find any evidence that it's acceptable to interleave multiple > > writers that are doing O_APPEND? At best, to do what you're asking, > > they could be kept from being interleaved from the context of one > > specific NFS client host... > > As far as POSIX goes, the standard says that applications are expected > to handle serialization. It makes no exception for O_APPEND. Then let's fix IO_UNIT so the existing code can DTRT. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 15:54:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC8916A4CE for ; Fri, 22 Apr 2005 15:54:35 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31E4F43D31 for ; Fri, 22 Apr 2005 15:54:35 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) id 41E3216700E8A9C4; Fri, 22 Apr 2005 17:54:34 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 22 Apr 2005 17:54:29 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050422153320.E99665D07@ptavv.es.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVHUJ5gd9d2PrKDS+OGpe0wByJyggAAp/Ag Subject: RE: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 15:54:35 -0000 Kevin Oberman wrote: > I had been seeing similar problems (very painful to get anything done) > for several days, but the kernel I built from CURRENT as of > 2005.04.20.16.29.00 seems to have fixed the problem for me. Unfortunately I'm still seeing it on a kernel from today. But thanks for confirming that something is icky in the disc I/O-path (both ATA and SCSI). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 16:00:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C43C16A4CE for ; Fri, 22 Apr 2005 16:00:17 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B5A543D39 for ; Fri, 22 Apr 2005 16:00:12 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3MG1meQ001573; Fri, 22 Apr 2005 10:01:48 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42691EC2.7080106@samsco.org> Date: Fri, 22 Apr 2005 09:56:50 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: 'FreeBSD Current' Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 16:00:17 -0000 Daniel Eriksson wrote: > With recent CURRENT (at least for the last 2 days, but probably longer), two > of my systems can be brought to their knees (live-lock) with a simple "dd > if=/dev/zero of=test bs=128k" command. I have not tested any other systems. > > I keep both servers synced running 6-CURRENT: > > Server #1: dual AthlonMP 2600+, Compaq SmartArray 5302/64 hardware raid card > (ciss). The card hosts two arrays, one RAID-5 built from 4 discs that holds > the system and one RAID-0 built from 14 discs. All the discs are 36GB 10krpm > and I have one array on each channel on the card. > > Server #2: AthlonXP 2500+ with an old Maxtor 27GB UDMA66 disc for the > system. > > > What made me take notice was that server #2 ran through a "make > installkernel; make installworld" faster than server #1 during a recent > upgrade. This makes no sense given the superior I/O performance of the > hardware scsi raid array on server #1, and I know that in the past server #1 > has finished the process ahead of server #2. > > After the upgrade was done I ran some simple tests with 'dd', and it only > took ~1 minute for the system to live-lock. Breaking into DDB and killing > the 'dd' process brought the machine back to life. I assumed the problem was > ciss-related, CAM-related or SMP-related, but I just tried doing the same > thing on the UP machine (server #2), and it too live-locked within a minute. > > Both systems use pretty much the same config, with the only major difference > being SMP or not: > * SCHED_4BSD, PREEMPTION, ADAPTIVE_GIANT, DEVICE_POLLING, HZ=2000 > * debug.mpsafenet="1", debug.mpsafevfs="1" What happens if you turn off mpsafevfs? Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 16:25:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ABF716A4CE for ; Fri, 22 Apr 2005 16:25:02 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7A2D43D1F for ; Fri, 22 Apr 2005 16:25:01 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP0xh-0003Ae-DM; Fri, 22 Apr 2005 16:25:01 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP0xa-0003f8-4G; Fri, 22 Apr 2005 06:24:54 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.9557.627987.505930@roam.psg.com> Date: Fri, 22 Apr 2005 06:24:53 -1000 To: FreeBSD Current Subject: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 16:25:02 -0000 on a 1ru system with an fxp yesterday, i cvsupped Apr 21 17:00 and built, first time in a few weeks previously i got an ipfw pullup failed a couple of times a day now i get them every few minutes anyone else seeing this, or should i start to send someone into the colo to check cables? randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 16:25:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 246C216A4CE for ; Fri, 22 Apr 2005 16:25:52 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C76E43D41 for ; Fri, 22 Apr 2005 16:25:51 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) id 41E3216700E8C394; Fri, 22 Apr 2005 18:25:49 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 22 Apr 2005 18:25:45 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42691EC2.7080106@samsco.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVHVGGWkR9e4jvcSuq6UBxCPJHi+QAAlc3A Subject: RE: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 16:25:52 -0000 Scott Long wrote: > What happens if you turn off mpsafevfs? At first I thought it had cured the problem, but after running 'dd' for ~3 minutes it started swapping, and about a minute later the system became completely unresponsive. Also, if I abort 'dd' after the swapping has started but before it live-locks it seems that a new 'dd' will take the system to that unresponsive state very quickly. I tested this on the UP system, newly rebooted. The system itself is pretty basic. More discs than normal, but they were not mounted (they are normally exported using ggate). Below is the dmesg just in case... /Daniel Eriksson Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #0: Fri Apr 22 06:48:40 CEST 2005 daniel@xxx:/usr/obj/usr/src/sys/XXX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2500+ (1833.13-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400000 real memory = 536850432 (511 MB) avail memory = 516022272 (492 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 0 on acpi0 pci_link2: irq 10 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 3 on acpi0 pci_link5: irq 7 on acpi0 pci_link6: irq 5 on acpi0 pci_link7: irq 15 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xfc000000-0xfdffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci0: at device 10.0 (no driver attached) re0: port 0xd800-0xd8ff mem 0xed800000-0xed8000ff at device 12.0 on pci0 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:50:fc:f8:c6:81 atapci0: port 0xd400-0xd407,0xd000-0xd003,0xb800-0xb807,0xb400-0xb403,0xb000-0xb0ff irq 16 at device 13.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0xa800-0xa807,0xa400-0xa403,0xa000-0xa007,0x9800-0x9803,0x9400-0x94ff irq 16 at device 13.1 on pci0 ata4: on atapci1 ata5: on atapci1 atapci2: port 0x9000-0x9007,0x8800-0x8803,0x8400-0x8407,0x8000-0x8003,0x7800-0x780f,0x7400 -0x74ff at device 15.0 on pci0 ata6: on atapci2 ata6: SATA connect ready time=0ms ata7: on atapci2 ata7: SATA connect ready time=0ms atapci3: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x7000-0x700f irq 20 at device 15.1 on pci0 ata0: on atapci3 ata1: on atapci3 uhci0: port 0x6800-0x681f at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x6400-0x641f at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x6000-0x601f at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x5800-0x581f at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xed000000-0xed0000ff at device 16.4 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x5400-0x54ff mem 0xec800000-0xec8000ff at device 18.0 on pci0 miibus1: on vr0 rlphy0: on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0e:a6:1f:29:1e atapci4: port 0x5000-0x503f,0x4800-0x480f,0x4400-0x447f mem 0xec000000-0xec000fff,0xeb800000-0xeb81ffff irq 18 at device 19.0 on pci0 ata8: on atapci4 ata8: SATA connect ready time=0ms ata9: on atapci4 ata9: SATA connect ready time=0ms ata10: on atapci4 ata10: SATA connect ready time=0ms ata11: on atapci4 ata11: SATA connect ready time=0ms sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcc7ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1833132661 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging unlimited ad0: 26059MB at ata0-master UDMA66 ad4: 190782MB at ata2-master UDMA100 GEOM_STRIPE: Device stripe_1200GB created (id=94156052). GEOM_STRIPE: Disk ad4 attached to stripe_1200GB. ad5: 190782MB at ata2-slave UDMA100 GEOM_STRIPE: Disk ad5 attached to stripe_1200GB. ad6: 190782MB at ata3-master UDMA100 GEOM_STRIPE: Disk ad6 attached to stripe_1200GB. ad7: 190782MB at ata3-slave UDMA100 GEOM_STRIPE: Disk ad7 attached to stripe_1200GB. ad8: 190782MB at ata4-master UDMA100 GEOM_STRIPE: Disk ad8 attached to stripe_1200GB. ad9: 190782MB at ata4-slave UDMA100 GEOM_STRIPE: Disk ad9 attached to stripe_1200GB. GEOM_STRIPE: Device stripe_1200GB activated. ad12: 238475MB at ata6-master SATA150 GEOM_STRIPE: Device stripe_500GB created (id=2719370432). GEOM_STRIPE: Disk ad12 attached to stripe_500GB. ad14: 238475MB at ata7-master SATA150 GEOM_STRIPE: Disk ad14 attached to stripe_500GB. GEOM_STRIPE: Device stripe_500GB activated. ad16: 238475MB at ata8-master SATA150 ad18: 239372MB at ata9-master SATA150 ad20: 239372MB at ata10-master SATA150 ad22: 238475MB at ata11-master SATA150 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s1a From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 16:30:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26F4916A4CE for ; Fri, 22 Apr 2005 16:30:09 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B1243D39 for ; Fri, 22 Apr 2005 16:30:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3MGViVN001685; Fri, 22 Apr 2005 10:31:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426925C7.3030004@samsco.org> Date: Fri, 22 Apr 2005 10:26:47 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: 'FreeBSD Current' Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 16:30:09 -0000 Daniel Eriksson wrote: > Scott Long wrote: > > >>What happens if you turn off mpsafevfs? > > > At first I thought it had cured the problem, but after running 'dd' for ~3 > minutes it started swapping, and about a minute later the system became > completely unresponsive. > > Also, if I abort 'dd' after the swapping has started but before it > live-locks it seems that a new 'dd' will take the system to that > unresponsive state very quickly. > > I tested this on the UP system, newly rebooted. The system itself is pretty > basic. More discs than normal, but they were not mounted (they are normally > exported using ggate). Below is the dmesg just in case... > > /Daniel Eriksson > Ok, next test would be to turn off mpsafevm. This is just a simple guess, though, but and changes in the behaviour would be very interesting to note. Scott From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 16:55:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF7716A4CF for ; Fri, 22 Apr 2005 16:55:40 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id A329143D5E for ; Fri, 22 Apr 2005 16:55:39 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 42687F20000328E3; Fri, 22 Apr 2005 18:55:38 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 22 Apr 2005 18:55:34 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <426925C7.3030004@samsco.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVHWI0baIiRdLYrR1ysbx0LE2ySYgAAr6cQ Subject: RE: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 16:55:40 -0000 Scott Long wrote: > Ok, next test would be to turn off mpsafevm. This is just a simple > guess, though, but and changes in the behaviour would be very > interesting to note. With debug.mpsafevfs="0" and debug.mpsafevm="0" it doesn't seem like I can force the machine into live-lock. No matter how long I let 'dd' run I can still abort it with CTRL-C easily. However, after a few minutes the machine becomes mostly useless because it takes 30-60 seconds to execute simple commands such as ps or ls. According to 'top', the dd process spend most of its time in "wdrain" state. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 17:18:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2780416A4CE for ; Fri, 22 Apr 2005 17:18:01 +0000 (GMT) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC3A43D1F for ; Fri, 22 Apr 2005 17:18:00 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j3MHI0Ah010014; Fri, 22 Apr 2005 10:18:00 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j3MHI0J0010013; Fri, 22 Apr 2005 10:18:00 -0700 (PDT) (envelope-from faber) Date: Fri, 22 Apr 2005 10:18:00 -0700 From: Ted Faber To: Randy Bush Message-ID: <20050422171800.GL7327@pun.isi.edu> References: <17001.9557.627987.505930@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yaPAUYI/0vT2YKpA" Content-Disposition: inline In-Reply-To: <17001.9557.627987.505930@roam.psg.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 17:18:01 -0000 --yaPAUYI/0vT2YKpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 22, 2005 at 06:24:53AM -1000, Randy Bush wrote: > on a 1ru system with an fxp > yesterday, i cvsupped Apr 21 17:00 and built, first time in a few weeks > previously i got an ipfw pullup failed a couple of times a day > now i get them every few minutes > > anyone else seeing this, or should i start to send someone into > the colo to check cables? I've seen a marked increase in the frequency of that message, too. pun:~$ uname -a FreeBSD pun.isi.edu 6.0-CURRENT FreeBSD 6.0-CURRENT #19: Thu Apr 21 13:55:26 PDT 2005 root@pun.isi.edu:/usr/obj/usr/src/sys/PUN i386 -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --yaPAUYI/0vT2YKpA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCaTHIaUz3f+Zf+XsRAqakAKCKKXaZG6/gTIJqa8wrP4Xbs56TTQCeOeVl 9WljqBw0NyQiuPvtCOMbK6o= =FqwF -----END PGP SIGNATURE----- --yaPAUYI/0vT2YKpA-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 17:34:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84D7816A4CE for ; Fri, 22 Apr 2005 17:34:35 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6113343D48 for ; Fri, 22 Apr 2005 17:34:35 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 55CFD72DE4; Fri, 22 Apr 2005 10:34:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 532CE72DDB; Fri, 22 Apr 2005 10:34:35 -0700 (PDT) Date: Fri, 22 Apr 2005 10:34:35 -0700 (PDT) From: Doug White To: Sebastian Schulze Struchtrup In-Reply-To: <4268E399.6030304@struchtrup.com> Message-ID: <20050422103316.G5855@carver.gumbysoft.com> References: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> <4268E399.6030304@struchtrup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Lars Engels cc: current@freebsd.org Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 17:34:35 -0000 On Fri, 22 Apr 2005, Sebastian Schulze Struchtrup wrote: > Gary Jennejohn wrote: > > >Lars Engels writes: > > > > > >>Hi all! > >> > >>I just upgraded my 5.4-PRERELEASE notebook to -CURRENT. > >>Compilation and installation went fine, but when I try to start firefox, > >>gkrellm and even portupgrade I get the following error message: > >>/libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: Undefined symbol > >>"i386_get_gsbase" > >> > >> > > > >It's not in UPDATING, but a change was recently made (can't say exactly > >when) which affects %gs/%fs. If you're using -current then you really > >should watch the commits, too! > > > >You'll have to recompile these ports, I suspect. Interestingly, my old > >gkrellm still runs just fine with a new world from yesterday, but I had > >to reinstall transcode. > > > > > > > > This was introduced by libpthread (and libkse, I think) using > i386_(get/set)_(gs/fs)base in libc The old libc.5 doesn't have this > functions implemented and is no longer rebuild as we're using libc.6 > now. This affects all ports which are still using libc.5 and > libpthread/libkse. The easiest approach is probably to rebuild all your > ports so that they are using libc.6 Anyway, libc.5 without pthreads/kse > works fine on my system. > > Maybe this should be placed into src/UPDATING? Yes. We also need to make sure 5.x compat works. I've raised the question as to what to do, as we have a couple of options and it depends on whether we can just bump the version and get away with it or if more involed hacks are necessary. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 17:35:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9325D16A4CE for ; Fri, 22 Apr 2005 17:35:04 +0000 (GMT) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4728C43D2D for ; Fri, 22 Apr 2005 17:35:04 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout2-sn1.fre.skanova.net (7.1.026.7) id 42687F2000034739; Fri, 22 Apr 2005 19:35:03 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Fri, 22 Apr 2005 19:34:59 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <17001.9557.627987.505930@roam.psg.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVHV/BYTU/fDlNWR4yXXD4f969IQAACMiog cc: 'Randy Bush' Subject: RE: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 17:35:04 -0000 Randy Bush wrote: > previously i got an ipfw pullup failed a couple of times a day > now i get them every few minutes I've gone from naver having seen one to 5-10 per day over the last week. Intel Pro/1000 (em) network card in one of the servers, VIA Rhine II (vr) in the other. They seem to happen at the same time on both servers even though they are hooked up to a switch, so that means some sort of broadcast. Could be the result of some new virus perhaps? At least one machine on the local segment is spamming snmp-trap broadcasts, possibly indicating some sort of virus propagation. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 17:36:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B39E116A4CE; Fri, 22 Apr 2005 17:36:48 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ABD243D49; Fri, 22 Apr 2005 17:36:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8E45B72DE4; Fri, 22 Apr 2005 10:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 8C65E72DDB; Fri, 22 Apr 2005 10:36:48 -0700 (PDT) Date: Fri, 22 Apr 2005 10:36:48 -0700 (PDT) From: Doug White To: David Xu In-Reply-To: <42674E61.9050005@freebsd.org> Message-ID: <20050422103554.N5855@carver.gumbysoft.com> References: <1114052573.1075.10.camel@dirk.no.domain> <42674E61.9050005@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Sam Lawrance Subject: Re: kern/78474 for 5.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 17:36:48 -0000 On Thu, 21 Apr 2005, David Xu wrote: > Sam Lawrance wrote: > > >Will this problem: > > > >Swapped out procs not brought in immediately after child exits > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > > > >be dealt with for the release of 5.4? > > > >Perhaps I'm the only FreeBSD user with swapped out processes ;-) > > > >-Sam > > > > > > > I don't know why people keep sending mail to me about the problem, I > received another > mail said that -CURRENT still has the problem, I will look those code, I > thought someone > ( I can not remember) had already fixed it in kern_exit.c. ;-) The PR is still makred 'open' and ther eis no indication that a fix has been committed. Can you update the audit trail and/or state accordingly? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 18:02:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7C5E16A4CE for ; Fri, 22 Apr 2005 18:02:10 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CC4843D55 for ; Fri, 22 Apr 2005 18:02:10 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) id j3MI2Ag7014536; Fri, 22 Apr 2005 11:02:10 -0700 (PDT) Received: from [10.1.1.245] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j3MI28rT028712; Fri, 22 Apr 2005 11:02:09 -0700 (PDT) In-Reply-To: <17001.9557.627987.505930@roam.psg.com> References: <17001.9557.627987.505930@roam.psg.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 22 Apr 2005 14:02:07 -0400 To: Randy Bush X-Mailer: Apple Mail (2.622) cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:02:10 -0000 On Apr 22, 2005, at 12:24 PM, Randy Bush wrote: > on a 1ru system with an fxp > yesterday, i cvsupped Apr 21 17:00 and built, first time in a few weeks > previously i got an ipfw pullup failed a couple of times a day > now i get them every few minutes > > anyone else seeing this, or should i start to send someone into > the colo to check cables? What it means is that the IPFW code didn't see a long enough packet to contain enough data to be logged usefully. That could be a sign of hardware problems like a flaky cable or a NIC that is going wonky: if you can check "netstat -i" and look for excessive input errors or collisions. If the machine is connected to a managed switch, look for "runt packets", smaller than 54 bytes (56?, whatever the minimum valid size is).... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 18:21:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44C2B16A4CE for ; Fri, 22 Apr 2005 18:21:05 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0980243D53 for ; Fri, 22 Apr 2005 18:21:05 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP2m0-0006PU-Nq; Fri, 22 Apr 2005 18:21:04 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP2lt-0003nb-CN; Fri, 22 Apr 2005 08:20:57 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.16520.774703.612151@roam.psg.com> Date: Fri, 22 Apr 2005 08:20:56 -1000 To: Charles Swiger References: <17001.9557.627987.505930@roam.psg.com> cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:21:05 -0000 >> on a 1ru system with an fxp >> yesterday, i cvsupped Apr 21 17:00 and built, first time in a few weeks >> previously i got an ipfw pullup failed a couple of times a day >> now i get them every few minutes >> >> anyone else seeing this, or should i start to send someone into >> the colo to check cables? > > What it means is that the IPFW code didn't see a long enough packet to > contain enough data to be logged usefully. That could be a sign of > hardware problems like a flaky cable or a NIC that is going wonky: if > you can check "netstat -i" and look for excessive input errors or > collisions. > > If the machine is connected to a managed switch, look for "runt > packets", smaller than 54 bytes (56?, whatever the minimum valid size > is).... sorry, did all that before whining. but, as i might not have, your asking was quite appropriate. # netstat -m 204 mbufs in use 134/13120 mbuf clusters in use (current/max) 0/4/3536 sfbufs in use (current/peak/max) 319 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:30:48:51:c8:5e 47087068 0 46603594 0 0 fxp0 1500 RG.NET/24 rip 47394365 - 47237789 - - fxp0 1500 ssh/32 ssh 5129 - 0 - - fxp1* 1500 00:30:48:51:c8:5f 0 0 0 0 0 lo0 16384 857260 0 857260 0 0 lo0 16384 your-net localhost 223262 - 223262 - - it appears to be a plain increase in the reporting of pullup failed. randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 18:22:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12D3E16A4CE for ; Fri, 22 Apr 2005 18:22:47 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B7043D3F for ; Fri, 22 Apr 2005 18:22:46 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j3MIMksG070624; Fri, 22 Apr 2005 11:22:46 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j3MIMkPc070623; Fri, 22 Apr 2005 11:22:46 -0700 (PDT) (envelope-from rizzo) Date: Fri, 22 Apr 2005 11:22:46 -0700 From: Luigi Rizzo To: Randy Bush Message-ID: <20050422112246.A70611@xorpc.icir.org> References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17001.16520.774703.612151@roam.psg.com>; from randy@psg.com on Fri, Apr 22, 2005 at 08:20:56AM -1000 cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:22:47 -0000 wonder if it is related to the recent import of ipfw v6 support... cheers luigi On Fri, Apr 22, 2005 at 08:20:56AM -1000, Randy Bush wrote: > >> on a 1ru system with an fxp > >> yesterday, i cvsupped Apr 21 17:00 and built, first time in a few weeks > >> previously i got an ipfw pullup failed a couple of times a day > >> now i get them every few minutes > >> > >> anyone else seeing this, or should i start to send someone into > >> the colo to check cables? > > > > What it means is that the IPFW code didn't see a long enough packet to > > contain enough data to be logged usefully. That could be a sign of > > hardware problems like a flaky cable or a NIC that is going wonky: if > > you can check "netstat -i" and look for excessive input errors or > > collisions. > > > > If the machine is connected to a managed switch, look for "runt > > packets", smaller than 54 bytes (56?, whatever the minimum valid size > > is).... > > sorry, did all that before whining. but, as i might not have, > your asking was quite appropriate. > > # netstat -m > 204 mbufs in use > 134/13120 mbuf clusters in use (current/max) > 0/4/3536 sfbufs in use (current/peak/max) > 319 KBytes allocated to network > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > # netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > fxp0 1500 00:30:48:51:c8:5e 47087068 0 46603594 0 0 > fxp0 1500 RG.NET/24 rip 47394365 - 47237789 - - > fxp0 1500 ssh/32 ssh 5129 - 0 - - > fxp1* 1500 00:30:48:51:c8:5f 0 0 0 0 0 > lo0 16384 857260 0 857260 0 0 > lo0 16384 your-net localhost 223262 - 223262 - - > > it appears to be a plain increase in the reporting of pullup failed. > > randy > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 18:25:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D512916A4CE for ; Fri, 22 Apr 2005 18:25:08 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B228A43D3F for ; Fri, 22 Apr 2005 18:25:08 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP2pw-0006XW-F3; Fri, 22 Apr 2005 18:25:08 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP2pp-0003oY-3n; Fri, 22 Apr 2005 08:25:01 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.16764.512962.411616@roam.psg.com> Date: Fri, 22 Apr 2005 08:25:00 -1000 To: Luigi Rizzo References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:25:09 -0000 > wonder if it is related to the recent import of ipfw v6 support... could be, no idea really. but fwiw, ipv6 is not enabled here. randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 18:55:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02D0A16A4CE for ; Fri, 22 Apr 2005 18:55:21 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDAD343D58 for ; Fri, 22 Apr 2005 18:55:18 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id j3MItIjB070932; Fri, 22 Apr 2005 11:55:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j3MItIP3070931; Fri, 22 Apr 2005 11:55:18 -0700 (PDT) (envelope-from rizzo) Date: Fri, 22 Apr 2005 11:55:18 -0700 From: Luigi Rizzo To: Randy Bush Message-ID: <20050422115518.C70611@xorpc.icir.org> References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> <17001.16764.512962.411616@roam.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17001.16764.512962.411616@roam.psg.com>; from randy@psg.com on Fri, Apr 22, 2005 at 08:25:00AM -1000 cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:55:21 -0000 On Fri, Apr 22, 2005 at 08:25:00AM -1000, Randy Bush wrote: > > wonder if it is related to the recent import of ipfw v6 support... > > could be, no idea really. but fwiw, ipv6 is not enabled here. yes but there is some new code in the common path. anyways i have cc-ed Brooks who committed the code (originally written by my students) so he can have a look cheers luigi > randy > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 21:00:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ED1B16A4D5 for ; Fri, 22 Apr 2005 21:00:19 +0000 (GMT) Received: from hq.sectorb.msk.ru (petaflop.b.gz.ru [217.67.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3988743D46 for ; Fri, 22 Apr 2005 21:00:15 +0000 (GMT) (envelope-from chinhngt@sectorb.msk.ru) Received: from it.hackers (it.hackers [172.16.37.1]) by hq.sectorb.msk.ru (Postfix) with ESMTP id EA518819F for ; Sat, 23 Apr 2005 01:00:12 +0400 (MSD) Date: Sat, 23 Apr 2005 01:01:52 +0400 (MSD) From: Nguyen Tam Chinh X-X-Sender: chinhngt@it.hackers To: current@FreeBSD.org Message-ID: <20050423005715.G16129@it.hackers> X-Operating-System: FreeBSD 5.3-STABLE Keywords: 216091683 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: mgadrm fail in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 21:00:19 -0000 Hello All, I've just compiled -CURRENT (cvsup some hours ago) and the magdrm seemed to be fail. Last week's -CURRENT build was okay. MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC cc -c -O2 -pipe -ffast-math -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vers.c linking kernel mga_dma.o(.text+0xa): In function `mga_do_wait_for_idle': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x97): In function `mga_do_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x142): In function `mga_do_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x15e): In function `mga_do_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x179): In function `mga_do_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1b1): more undefined references to `drm_debug_flag' follow mga_dma.o(.text+0x6f4): In function `mga_do_cleanup_dma': : undefined reference to `drm_free' mga_dma.o(.text+0x726): In function `mga_do_cleanup_dma': : undefined reference to `drm_free' mga_dma.o(.text+0x758): In function `mga_do_cleanup_dma': : undefined reference to `drm_ioremapfree' mga_dma.o(.text+0x765): In function `mga_do_cleanup_dma': : undefined reference to `drm_irq_uninstall' mga_dma.o(.text+0x7a5): In function `mga_do_cleanup_dma': : undefined reference to `drm_ioremapfree' mga_dma.o(.text+0x7da): In function `mga_do_cleanup_dma': : undefined reference to `drm_ioremapfree' mga_dma.o(.text+0x899): In function `mga_dma_init': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x8b5): In function `mga_dma_init': : undefined reference to `drm_alloc' mga_dma.o(.text+0xa62): In function `mga_dma_init': : undefined reference to `drm_ioremap' mga_dma.o(.text+0xa77): In function `mga_dma_init': : undefined reference to `drm_ioremap' mga_dma.o(.text+0xa8c): In function `mga_dma_init': : undefined reference to `drm_ioremap' mga_dma.o(.text+0xce6): In function `mga_dma_init': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0xd02): In function `mga_dma_init': : undefined reference to `drm_alloc' mga_dma.o(.text+0xe27): In function `mga_dma_init': : undefined reference to `drm_alloc' mga_dma.o(.text+0xf1f): In function `mga_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1043): In function `mga_dma_reset': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1261): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1321): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x135b): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x144e): more undefined references to `drm_debug_flag' follow mga_drv.o(.text+0x15): In function `mga_probe': mga_dma.o(.text+0xce6): In function `mga_dma_init': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0xd02): In function `mga_dma_init': : undefined reference to `drm_alloc' mga_dma.o(.text+0xe27): In function `mga_dma_init': : undefined reference to `drm_alloc' mga_dma.o(.text+0xf1f): In function `mga_dma_flush': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1043): In function `mga_dma_reset': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1261): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x1321): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x135b): In function `mga_dma_buffers': : undefined reference to `drm_debug_flag' mga_dma.o(.text+0x144e): more undefined references to `drm_debug_flag' follow mga_drv.o(.text+0x15): In function `mga_probe': : undefined reference to `drm_probe' mga_drv.o(.text+0xdd): In function `mga_attach': : undefined reference to `drm_attach' mga_drv.o(.data+0x48): undefined reference to `drm_devclass' mga_drv.o(.data+0x94): undefined reference to `drm_detach' mga_irq.o(.text+0x51): In function `mga_driver_irq_handler': : undefined reference to `drm_vbl_send_signals' mga_state.o(.text+0xa64): In function `mga_dma_clear': : undefined reference to `drm_debug_flag' mga_state.o(.text+0xc40): In function `mga_dma_clear': : undefined reference to `drm_debug_flag' mga_state.o(.text+0xe07): In function `mga_dma_swap': : undefined reference to `drm_debug_flag' mga_state.o(.text+0xf3b): In function `mga_dma_swap': : undefined reference to `drm_debug_flag' mga_state.o(.text+0xfd6): In function `mga_dma_swap': : undefined reference to `drm_debug_flag' mga_state.o(.text+0x11ad): more undefined references to `drm_debug_flag' follow *** Error code 1 Stop in /mnt/music/Temp/obj/usr/src/sys/kernel. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. chinhngt@it# ----- With best regards, | The Power to Serve Nguyen Tam Chinh | http://www.FreeBSD.org Loc: sp.cs.msu.ru | From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 21:44:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A11416A4CE for ; Fri, 22 Apr 2005 21:44:20 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CBB43D2D for ; Fri, 22 Apr 2005 21:44:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3MLiI4x004255; Fri, 22 Apr 2005 14:44:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3MLiIJ4004254; Fri, 22 Apr 2005 14:44:18 -0700 Date: Fri, 22 Apr 2005 14:44:18 -0700 From: Brooks Davis To: Luigi Rizzo Message-ID: <20050422214418.GB11806@odin.ac.hmc.edu> References: <17001.9557.627987.505930@roam.psg.com> <17001.16520.774703.612151@roam.psg.com> <20050422112246.A70611@xorpc.icir.org> <17001.16764.512962.411616@roam.psg.com> <20050422115518.C70611@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20050422115518.C70611@xorpc.icir.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Randy Bush cc: FreeBSD Current Subject: Re: significant increase in ipfw pullup failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 21:44:20 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 11:55:18AM -0700, Luigi Rizzo wrote: > On Fri, Apr 22, 2005 at 08:25:00AM -1000, Randy Bush wrote: > > > wonder if it is related to the recent import of ipfw v6 support... > >=20 > > could be, no idea really. but fwiw, ipv6 is not enabled here. >=20 > yes but there is some new code in the common path. > anyways i have cc-ed Brooks who committed the code I suspect this is due to over agressive pullups of icmp packets (at least that's the most obvious place where the length changed) which are caused by poor design of the icmp struct. We're pulling up the full length and should instead be pulling up 4 bytes. I'm not sure what the best fix it. Long term, creating a struct icmphdr is probably the right answer. For now, the thing to do may be to add it and use it in ipfw, but not modify struct icmp just yet. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCaXAxXY6L6fI4GtQRAnRaAKCE7ahNWiqco+zHtmSZOOGkXvrfDwCgqwCR b7ySf+Mw6ysvxaK2YuCtIWU= =75ub -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 23:06:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE7416A4CE for ; Fri, 22 Apr 2005 23:06:16 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA56743D45 for ; Fri, 22 Apr 2005 23:06:15 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3MN63js075614; Fri, 22 Apr 2005 19:06:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3MN619j075609; Fri, 22 Apr 2005 19:06:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 22 Apr 2005 19:06:01 -0400 (EDT) From: Andre Guibert de Bruet To: Matthew Sullivan In-Reply-To: <4267A1CF.3080903@uq.edu.au> Message-ID: <20050422190208.M68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.542, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 23:06:16 -0000 On Thu, 21 Apr 2005, Matthew Sullivan wrote: > I've been reading about problems with HP/Compaq's regarding launching of > second CPUs on SMP systems. > > I've been through the BIOS settings and there seems to be no settings to > change the APCI table etc.... > > Now one thing that does seem common, when I have BIOS's with MP table version > set to 1.4 FreeBSD doesn't report the second CPU being launched (even though > it is seen in the acpidump).... When I set the BIOS to version 1.2 of the MP > table the second CPU is reported and launched. > > Now the Compaq DL380's I have done seem to have the ability to set 1.4 or 1.2 > of the table ... mptable reports 1.4... (below) > > Any suggestions on how to launch the second CPU...? Make a boot -v from this machine available. Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 23:07:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB66E16A4CE for ; Fri, 22 Apr 2005 23:07:04 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2EA143D41 for ; Fri, 22 Apr 2005 23:07:04 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Fri, 22 Apr 2005 16:07:04 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1D9FB5D08; Fri, 22 Apr 2005 16:07:04 -0700 (PDT) To: "Daniel Eriksson" In-reply-to: Your message of "Fri, 22 Apr 2005 18:55:34 +0200." Date: Fri, 22 Apr 2005 16:07:04 -0700 From: "Kevin Oberman" Message-Id: <20050422230704.1D9FB5D08@ptavv.es.net> cc: 'FreeBSD Current' Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 23:07:05 -0000 > From: "Daniel Eriksson" > Date: Fri, 22 Apr 2005 18:55:34 +0200 > Sender: owner-freebsd-current@freebsd.org > > Scott Long wrote: > > > Ok, next test would be to turn off mpsafevm. This is just a simple > > guess, though, but and changes in the behaviour would be very > > interesting to note. > > With debug.mpsafevfs="0" and debug.mpsafevm="0" it doesn't seem like I can > force the machine into live-lock. No matter how long I let 'dd' run I can > still abort it with CTRL-C easily. However, after a few minutes the machine > becomes mostly useless because it takes 30-60 seconds to execute simple > commands such as ps or ls. > > According to 'top', the dd process spend most of its time in "wdrain" state. > > /Daniel Eriksson This certainly makes something to do with VM seem like the culprit, but I thought I'd post information on what I am seeing in hopes that it might help. I am still seeing the live-locks, too. They seem to happen when I have a CPU intensive process running. I have seen it with evolution, and transcode. The behavior is odd in that some things run fine. I can leave top running and it updates like normal and accepts commands like kill and renice. But I can get an interactive prompt either in X or on a vty. Suspending the CPU intensive process immediately frees up the live-lock. Running the CPU intensive job a nice 10 does not help. My Gnome applets are fine and seem to be very responsive. I have seen gkrellm lock up, but it usually does not. I am running ULE, so it's not 4BSD specific. I am also running PREEMPTION. System is an IBM T30 with 1.8 GHz CPU and .5 GB RAM. the kernel does not include SMP or APIC but does run ACPI. I am providing this in hopes of narrowing things down. The live-lock problem is not the cause of the I/O issues I was having with my fxp Ethernet or with my secondary IDE bus. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 23:26:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35DB116A4CE for ; Fri, 22 Apr 2005 23:26:23 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF36E43D2D for ; Fri, 22 Apr 2005 23:26:22 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.3/8.13.1) with ESMTP id j3MNQLGZ009709; Fri, 22 Apr 2005 16:26:22 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.3/8.13.1/Submit) id j3MNQKiH009708; Fri, 22 Apr 2005 16:26:20 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Nguyen Tam Chinh In-Reply-To: <20050423005715.G16129@it.hackers> References: <20050423005715.G16129@it.hackers> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 22 Apr 2005 16:26:19 -0700 Message-Id: <1114212379.955.15.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.0 FreeBSD GNOME Team Port cc: current@freebsd.org Subject: Re: mgadrm fail in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 23:26:23 -0000 On Sat, 2005-04-23 at 01:01 +0400, Nguyen Tam Chinh wrote: > Hello All, > I've just compiled -CURRENT (cvsup some hours ago) and the magdrm seemed > to be fail. > Last week's -CURRENT build was okay. Do you have device drm in your kernel? Did you do a clean build? There's no real reason to be building the drm into the kernel that I can see, as it's automatically loaded for you by the X Server. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 01:33:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61C5016A4CE for ; Sat, 23 Apr 2005 01:33:47 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B36343D6B for ; Sat, 23 Apr 2005 01:33:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP9Wk-0000TH-7c; Sat, 23 Apr 2005 01:33:46 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DP9Wb-0000gy-RM; Fri, 22 Apr 2005 15:33:37 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.42481.325920.113852@roam.psg.com> Date: Fri, 22 Apr 2005 15:33:37 -1000 To: FreeBSD Current Subject: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 01:33:47 -0000 FreeBSD foo.bar.org 6.0-CURRENT FreeBSD 6.0-CURRENT #22: Thu Apr 21 19:09:22 GMT 2005 root@foo.bar.org:/usr/obj/usr/src/sys/FOO i386 locks up where it will echo typing on console or ssh, but hit CR and that session locks. i.e. probably some locked disk issue did manage to get a reboot command in Syncing disks, vnodes remaining...2 2 ipfw: pullup failed 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 timed out Syncing disks, buffers remaining... 24 24 24 24 24 24 24 1 24 24 1 24 24 24 1 24 1 24 24 1 24 1 24 1 24 24 1 24 1 Giving up on 24 buffers Uptime: 1d5h8m13s Shutting down ACPI Rebooting... savecore sez no dump randy From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 02:14:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF59716A4CF for ; Sat, 23 Apr 2005 02:14:38 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 733F343D3F for ; Sat, 23 Apr 2005 02:14:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 772B451326; Fri, 22 Apr 2005 19:14:37 -0700 (PDT) Date: Fri, 22 Apr 2005 19:14:37 -0700 From: Kris Kennaway To: Randy Bush Message-ID: <20050423021437.GA10800@xor.obsecurity.org> References: <17001.42481.325920.113852@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <17001.42481.325920.113852@roam.psg.com> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current Subject: Re: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 02:14:39 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2005 at 03:33:37PM -1000, Randy Bush wrote: > FreeBSD foo.bar.org 6.0-CURRENT FreeBSD 6.0-CURRENT #22: Thu Apr 21 19:09= :22 GMT 2005 root@foo.bar.org:/usr/obj/usr/src/sys/FOO i386 >=20 > locks up where it will echo typing on console or ssh, but hit CR and that > session locks. i.e. probably some locked disk issue Can you break to DDB and trace the process? Kris --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCaa+NWry0BWjoQKURAlQSAJ4mRz5loUQEwkrbveXegxgpp5QF5QCfaNCj qOPV7RYBwAzm/a/nWmOWR1Y= =82Fe -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 02:20:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32F3416A4CE for ; Sat, 23 Apr 2005 02:20:07 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A3C43D2D for ; Sat, 23 Apr 2005 02:20:07 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DPAFa-0008bT-RK; Sat, 23 Apr 2005 02:20:06 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DPAFR-0000kn-JL; Fri, 22 Apr 2005 16:19:57 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.45261.55150.150100@roam.psg.com> Date: Fri, 22 Apr 2005 16:19:57 -1000 To: Kris Kennaway References: <17001.42481.325920.113852@roam.psg.com> <20050423021437.GA10800@xor.obsecurity.org> cc: FreeBSD Current Subject: Re: disk freeze? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 02:20:07 -0000 > On Fri, Apr 22, 2005 at 03:33:37PM -1000, Randy Bush wrote: >> FreeBSD foo.bar.org 6.0-CURRENT FreeBSD 6.0-CURRENT #22: Thu Apr 21 19:09:22 GMT 2005 root@foo.bar.org:/usr/obj/usr/src/sys/FOO i386 >> >> locks up where it will echo typing on console or ssh, but hit CR and that >> session locks. i.e. probably some locked disk issue > Can you break to DDB and trace the process? no, i was unable to. heck, my laptop, also current, froze up today and i was unable to break from a real keyboard. but additional info; an rdump was happening, and this happened previously with an rdump. so, i can probably lock it up again by doing the rdump. but how should i wire it for sound before lighting the fuse? randy From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 03:03:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B05116A4CE; Sat, 23 Apr 2005 03:03:02 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB4D43D2D; Sat, 23 Apr 2005 03:03:02 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4366872DDB; Fri, 22 Apr 2005 20:03:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3E81F72DD4; Fri, 22 Apr 2005 20:03:02 -0700 (PDT) Date: Fri, 22 Apr 2005 20:03:02 -0700 (PDT) From: Doug White To: David Xu In-Reply-To: <42678DC4.40309@freebsd.org> Message-ID: <20050422200102.G10333@carver.gumbysoft.com> References: <1114052573.1075.10.camel@dirk.no.domain> <42678DC4.40309@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Sam Lawrance Subject: Re: kern/78474 for 5.4? (kernel stack swapout problem again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 03:03:02 -0000 On Thu, 21 Apr 2005, David Xu wrote: > Sam Lawrance wrote: > > >Will this problem: > > > >Swapped out procs not brought in immediately after child exits > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > > > >be dealt with for the release of 5.4? > > > >Perhaps I'm the only FreeBSD user with swapped out processes ;-) > > > >-Sam > > > > > > > > > > I have noticed that current spinlock implementation no longer means that > CPU must be in critical region (critical_enter is called), even previous > hack TDP_WAKEPROC0 is no longer correct, :(, I think it is the time to > disable swapout. I'm sorry, I can't parse your double negative. On -CURRENT critical sections (entered with critical_enter()) no longer disable interrupts, but do inhibit preemption. But spinlocks still do critical_enter() (see spinlock_enter()). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 03:15:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC82F16A4CE for ; Sat, 23 Apr 2005 03:15:56 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AFDD43D31 for ; Sat, 23 Apr 2005 03:15:56 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5BA5A72DDB; Fri, 22 Apr 2005 20:15:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5709672DD4; Fri, 22 Apr 2005 20:15:56 -0700 (PDT) Date: Fri, 22 Apr 2005 20:15:56 -0700 (PDT) From: Doug White To: Danny Braniss In-Reply-To: Message-ID: <20050422200953.N10333@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: diskless/unionfs panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 03:15:56 -0000 On Fri, 22 Apr 2005, Danny Braniss wrote: > hi, > after much debugging, it seems that the main problem with unionfs is > that if it's called early in the boot process it will panic the kernel: > > trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xffffffff8038e3f5 > stack pointer = 0x10:0xffffffffb1eac7b0 > frame pointer = 0x10:0xffffffffb1eac7e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 213 (sh) > [thread pid 213 tid 100066 ] > Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) unintialized mutex, probably, although it looks like it'd be the vm page queue mutex which should be init'd by then. Is this -CURRENT? > db> tr > Tracing pid 213 tid 100066 td 0xffffff007b9b1000 > _mtx_lock_flags() at _mtx_lock_flags+0x35 > exec_map_first_page() at exec_map_first_page+0x60 If you have a debug kernel for this around, load it into gdb and 'disass exec_map_first_page' and look around offset 96 to see if its referencing a mutex (mtx) near there. > kern_execve() at kern_execve+0x2a0 > execve() at execve+0x5d > syscall() at syscall+0x4ab > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = > 0x7fffffffcbf8, rbp = 0 --- > > doing the unionfs stuff sometime later - after the single user prompt - seems > do be ok. > > another thing, there are some LOR caused by the unionfs & md: > extarct of rc.d/initdiskless: > > if [ -e /conf/union ]; then > if ! sysctl vfs.uniondebug >/dev/null 2>&1; then > echo Loading unionfs > kldload unionfs > fi > echo Doing UNIONFS > mount_md 4096 /conf/etc > chmod 755 /conf/etc > mount_unionfs /conf/etc /etc > ls -R /etc > /dev/null > touch /etc/.sentinel > md_created_etc=created > fi > ... > > Loading unionfs > lock order reversal > 1st 0xffffff007c3b00f0 system map (system map) @ /r+d/6.0/src/sys/vm/vm_map.c: > 1100 > 2nd 0xffffff00623d8620 vm object (standard object) @ > /r+d/6.0/src/sys/vm/vm_map.c:897 > KDB: stack backtrace: > witness_checkorder() at witness_checkorder+0x5f1 > _mtx_lock_flags() at _mtx_lock_flags+0x4a > vm_map_insert() at vm_map_insert+0x115 > vm_map_find() at vm_map_find+0x9d > link_elf_load_file() at link_elf_load_file+0x811 > linker_load_module() at linker_load_module+0x50e > kldload() at kldload+0xc3 > syscall() at syscall+0x4ab > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067950c, rsp = > 0x7fffffffedf8, rbp = 0x7fffffffee68 --- > > Doing UNIONFS > lock order reversal > 1st 0xffffffff80892040 vm page queue mutex (vm page queue mutex) @ > /r+d/6.0/src/sys/kern/vfs_bio.c:1485 > 2nd 0xffffff0061dc98b0 vnode interlock (vnode interlock) @ > /r+d/6.0/src/sys/kern/vfs_subr.c:1992 > KDB: stack backtrace: > witness_checkorder() at witness_checkorder+0x5f1 > _mtx_lock_flags() at _mtx_lock_flags+0x4a > vdrop() at vdrop+0x31 > vm_page_remove() at vm_page_remove+0x126 > vm_page_free_toq() at vm_page_free_toq+0x61 > vm_page_free() at vm_page_free+0x1e > vfs_vmio_release() at vfs_vmio_release+0x18f > brelse() at brelse+0x792 > ffs_mount() at ffs_mount+0x121b > vfs_donmount() at vfs_donmount+0xaa3 > kernel_mount() at kernel_mount+0xaf > ffs_cmount() at ffs_cmount+0x92 > mount() at mount+0x132 > syscall() at syscall+0x1fb > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (21, FreeBSD ELF64, mount), rip = 0x80067e68c, rsp = > 0x7fffffffdf98, rbp = 0x7fffffffea58 --- > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 03:35:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D60916A4CE for ; Sat, 23 Apr 2005 03:35:57 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C6AC43D39 for ; Sat, 23 Apr 2005 03:35:56 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFD0050ERCIQU@nemesis.sorbs.net> for freebsd-current@freebsd.org; Sat, 23 Apr 2005 13:36:19 +1000 (EST) Date: Sat, 23 Apr 2005 13:34:41 +1000 From: Matthew Sullivan In-reply-to: <20050422190208.M68772@lexi.siliconlandmark.com> To: Andre Guibert de Bruet Message-id: <4269C251.8070504@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms040705030303040702020802; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 03:35:57 -0000 This is a cryptographically signed message in MIME format. --------------ms040705030303040702020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Guibert de Bruet wrote: > > On Thu, 21 Apr 2005, Matthew Sullivan wrote: > >> I've been reading about problems with HP/Compaq's regarding launching >> of second CPUs on SMP systems. >> >> I've been through the BIOS settings and there seems to be no settings >> to change the APCI table etc.... >> >> Now one thing that does seem common, when I have BIOS's with MP table >> version set to 1.4 FreeBSD doesn't report the second CPU being >> launched (even though it is seen in the acpidump).... When I set the >> BIOS to version 1.2 of the MP table the second CPU is reported and >> launched. >> >> Now the Compaq DL380's I have done seem to have the ability to set >> 1.4 or 1.2 of the table ... mptable reports 1.4... (below) >> >> Any suggestions on how to launch the second CPU...? > > > Make a boot -v from this machine available. http://scorpion.sorbs.net/dmesg.txt Cheers, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040705030303040702020802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMzAzMzQ0MlowIwYJKoZIhvcNAQkEMRYEFGEdmHdCmIkGEUfQ PN6L7hyoXj0rMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQE1+eBqlzrDJP455JaptqJZPUayda11bUXnZrZIFME/BJfVXymLUduPQRo2jLQqzzX9D B3nHW3f3VVKB5CeXffAAAAAAAAA= --------------ms040705030303040702020802-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 03:37:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F70B16A4CE for ; Sat, 23 Apr 2005 03:37:39 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3314243D54; Sat, 23 Apr 2005 03:37:39 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3N3baAr034032; Sat, 23 Apr 2005 03:37:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4269C309.30702@freebsd.org> Date: Sat, 23 Apr 2005 11:37:45 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug White References: <1114052573.1075.10.camel@dirk.no.domain> <42678DC4.40309@freebsd.org> <20050422200102.G10333@carver.gumbysoft.com> In-Reply-To: <20050422200102.G10333@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Sam Lawrance Subject: Re: kern/78474 for 5.4? (kernel stack swapout problem again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 03:37:39 -0000 Doug White wrote: >On Thu, 21 Apr 2005, David Xu wrote: > > > >>Sam Lawrance wrote: >> >> >> >>>Will this problem: >>> >>>Swapped out procs not brought in immediately after child exits >>>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 >>> >>>be dealt with for the release of 5.4? >>> >>>Perhaps I'm the only FreeBSD user with swapped out processes ;-) >>> >>>-Sam >>> >>> >>> >>> >>> >>> >>I have noticed that current spinlock implementation no longer means that >>CPU must be in critical region (critical_enter is called), even previous >>hack TDP_WAKEPROC0 is no longer correct, :(, I think it is the time to >>disable swapout. >> >> > >I'm sorry, I can't parse your double negative. On -CURRENT critical >sections (entered with critical_enter()) no longer disable interrupts, but >do inhibit preemption. But spinlocks still do critical_enter() (see >spinlock_enter()). > > > I will commit the patch provided in the PR, it should work. I am just worrying TDP_WAKEPROC0 will not work if spinlock does not entering critical region. From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 03:46:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F09616A4CE; Sat, 23 Apr 2005 03:46:15 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D02643D2D; Sat, 23 Apr 2005 03:46:14 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2451.dyn.pacific.net.au (ppp2451.dyn.pacific.net.au [61.8.36.81])j3N3k6Gc021717; Sat, 23 Apr 2005 13:46:07 +1000 From: Sam Lawrance To: David Xu In-Reply-To: <4269C309.30702@freebsd.org> References: <1114052573.1075.10.camel@dirk.no.domain> <20050422200102.G10333@carver.gumbysoft.com> <4269C309.30702@freebsd.org> Content-Type: text/plain Date: Sat, 23 Apr 2005 13:46:25 +1000 Message-Id: <1114227985.69709.6.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: kern/78474 for 5.4? (kernel stack swapout problem again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 03:46:15 -0000 On Sat, 2005-04-23 at 11:37 +0800, David Xu wrote: > Doug White wrote: > > >On Thu, 21 Apr 2005, David Xu wrote: > > > > > > > >>Sam Lawrance wrote: > >> > >> > >> > >>>Will this problem: > >>> > >>>Swapped out procs not brought in immediately after child exits > >>>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78474 > >>> > >>>be dealt with for the release of 5.4? > >>> > >>>Perhaps I'm the only FreeBSD user with swapped out processes ;-) > >>> > >>>-Sam > >>> > >>> > >>> > >>> > >>> > >>> > >>I have noticed that current spinlock implementation no longer means that > >>CPU must be in critical region (critical_enter is called), even previous > >>hack TDP_WAKEPROC0 is no longer correct, :(, I think it is the time to > >>disable swapout. > >> > >> > > > >I'm sorry, I can't parse your double negative. On -CURRENT critical > >sections (entered with critical_enter()) no longer disable interrupts, but > >do inhibit preemption. But spinlocks still do critical_enter() (see > >spinlock_enter()). > > > > > > > I will commit the patch provided in the PR, it should work. I am just > worrying > TDP_WAKEPROC0 will not work if spinlock does not entering critical region. If it's any comfort, using that patch, I've not had any swap-in delay problems since i raised the PR in early March. Running with all the typical debugging options turned on, and no problems arose. -Sam From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 06:05:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC20816A4CE; Sat, 23 Apr 2005 06:05:02 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65FE643D45; Sat, 23 Apr 2005 06:05:02 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3N651rK005664; Sat, 23 Apr 2005 02:05:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3N65Q86015946; Sat, 23 Apr 2005 02:05:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 77DD27306E; Sat, 23 Apr 2005 02:05:01 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050423060501.77DD27306E@freebsd-current.sentex.ca> Date: Sat, 23 Apr 2005 02:05:01 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.82, clamav-milter version 0.82 on clamscanner4 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:05:03 -0000 TB --- 2005-04-23 03:47:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-23 03:47:03 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-04-23 03:47:04 - checking out the source tree TB --- 2005-04-23 03:47:04 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-04-23 03:47:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-23 03:53:47 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-23 03:53:47 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-23 03:53:47 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-04-23 05:32:12 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-23 05:32:12 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-23 05:32:12 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Apr 23 05:32:13 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Apr 23 05:57:09 UTC 2005 TB --- 2005-04-23 05:57:09 - generating LINT kernel config TB --- 2005-04-23 05:57:09 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2005-04-23 05:57:09 - /usr/bin/make -B LINT TB --- 2005-04-23 05:57:10 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-23 05:57:10 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-04-23 05:57:10 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 23 05:57:11 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/amd64/amd64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-ta bles -ffreestanding -Werror /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:45: /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/amd64/amd64/src/sys/dev/acpica/Osd/OsdDebug.c:43: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-04-23 06:05:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-23 06:05:01 - ERROR: failed to build lint kernel TB --- 2005-04-23 06:05:01 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 06:13:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55D9E16A4CE for ; Sat, 23 Apr 2005 06:13:39 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D672643D53 for ; Sat, 23 Apr 2005 06:13:38 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3N6DZHp093067; Sat, 23 Apr 2005 02:13:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3N6DZc6093064; Sat, 23 Apr 2005 02:13:35 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 02:13:35 -0400 (EDT) From: Andre Guibert de Bruet To: Matthew Sullivan In-Reply-To: <4269C251.8070504@uq.edu.au> Message-ID: <20050423020305.I68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <4269C251.8070504@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.535, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:13:39 -0000 On Sat, 23 Apr 2005, Matthew Sullivan wrote: > Andre Guibert de Bruet wrote: > >> On Thu, 21 Apr 2005, Matthew Sullivan wrote: >> >>> I've been reading about problems with HP/Compaq's regarding launching of >>> second CPUs on SMP systems. >>> >>> I've been through the BIOS settings and there seems to be no settings to >>> change the APCI table etc.... >>> >>> Now one thing that does seem common, when I have BIOS's with MP table >>> version set to 1.4 FreeBSD doesn't report the second CPU being launched >>> (even though it is seen in the acpidump).... When I set the BIOS to >>> version 1.2 of the MP table the second CPU is reported and launched. >>> >>> Now the Compaq DL380's I have done seem to have the ability to set 1.4 or >>> 1.2 of the table ... mptable reports 1.4... (below) >>> >>> Any suggestions on how to launch the second CPU...? >> >> Make a boot -v from this machine available. > > http://scorpion.sorbs.net/dmesg.txt The lack of the following seems to indicate that you do not have "device apic" enabled in your kernel config (You need "options SMP" as well to get FreeBSD to do more than just recognize both CPUs): FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: Please share your config and the steps that you are taking to build your kernel. Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 06:29:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F06E16A4CE for ; Sat, 23 Apr 2005 06:29:35 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3F843D31 for ; Sat, 23 Apr 2005 06:29:34 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3N6TVnd093201; Sat, 23 Apr 2005 02:29:31 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3N6TVxw093198; Sat, 23 Apr 2005 02:29:31 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 02:29:31 -0400 (EDT) From: Andre Guibert de Bruet To: othermark In-Reply-To: Message-ID: <20050423022707.J68772@lexi.siliconlandmark.com> References: <20050420214259.GA46821@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.536, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: LOR/page fault panic vfs_mountroot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:29:35 -0000 On Thu, 21 Apr 2005, othermark wrote: > In this kernel, if I boot to single user, and simply do 'sysctl -a' > I'll get this panic. Here's the output -- corruption seems to start at > hw.kbd.keymap_restrict_change: > > [...] > > hw.intr_storm_threshold: 500 > hw.availpages: 259958 > hw.bus.devctl_disable: 0 > hw.dc_quick: 1 > hw.ste.rxsyncs: 0 > hw.kbd.keymap_restrict_change: > 0 > hw.syscons.sa > Fer.keybonly: 1 > hw.syscons.bellat: 1 > hw.syscons.alsc_no_suspend_vt switch: 0 > hw.butrsdma.total_bpageaps: 544 > hw.busdm a.zone0.total_bp1ages: 512 > hw.bu2sdma.zone0.free_:bpages: 512 > aw. busdma.zone0.resperved_bpages: 0 > hw.busdma.zone0g.active_bpages: e0 > hw.busdma.zon e0.total_bouncedf: 0 > hw.busdma.zaone0.total_deferured: 0 > hw.busdmla.zone0.lowaddr:t 0xffffffff > hw. busdma.zone0.aliwgnment: 4096 > hwh.busdma.zone0.boiundary: 0 > hw.bulsdma.zone1.totale_bpages: 32 > hw. in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0x4ac0c092 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0703f88 > stack pointer = 0x28:0xe50a1b78 > frame pointer = 0x28:0xe50a1b78 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 73 (sysctl) > [thread pid 73 tid 100055 ] > Stopped at strlen+0x8: cmpb $0,0(%edx) As expected by the fault code, the unscrambled version of that is: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0x4ac0c092 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0703f88 stack pointer = 0x28:0xe50a1b78 frame pointer = 0x28:0xe50a1b78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 73 (sysctl) [thread pid 73 tid 100055 ] Stopped at strlen+0x8: cmpb $0,0(%edx) Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 06:42:29 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51EEA16A4CE for ; Sat, 23 Apr 2005 06:42:29 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8C3143D41 for ; Sat, 23 Apr 2005 06:42:28 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3N6gDfQ093288; Sat, 23 Apr 2005 02:42:13 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3N6gA08093285; Sat, 23 Apr 2005 02:42:10 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 02:42:10 -0400 (EDT) From: Andre Guibert de Bruet To: "Conrad J. Sabatier" In-Reply-To: <20050419130048.6e545269@dolphin.local.net> Message-ID: <20050423023605.A68772@lexi.siliconlandmark.com> References: <20050418232455.2d530890@dolphin.local.net> <5265.1113888748@critter.freebsd.dk> <20050419130048.6e545269@dolphin.local.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.536, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: FreeBSD MIDI (Was: Re: What happened to the "d_maj" member of"struct cdevsw" in CURRENT?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:42:29 -0000 On Tue, 19 Apr 2005, Conrad J. Sabatier wrote: > Still no support for my particular soundcard yet, though, unfortunately > (es137x), but Mat does intend to get to work on it Real Soon Now. > > It looks like MIDI is really starting to come together, though. I now > have a loadable kernel module "midi.ko", with support for cmi and > emu10k1 cards. I've already seen a report from someone on the > multimedia list who actually got this to work with his card > and external MIDI synth. Hopefully, we can get support for more cards > included soon. :-) > > We'll keep the current list informed as to further developments. I would love to get my Yamaha synth working with FreeBSD! What state are these patches in? Is this something that we could expect for 6.0-rel? Cheers! Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 06:45:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9202716A4CE for ; Sat, 23 Apr 2005 06:45:01 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07B5F43D39 for ; Sat, 23 Apr 2005 06:45:01 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3N6is4P093339; Sat, 23 Apr 2005 02:44:54 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3N6irdp093336; Sat, 23 Apr 2005 02:44:54 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 02:44:53 -0400 (EDT) From: Andre Guibert de Bruet To: Niklas Sorensson In-Reply-To: <20050421220902.GA2960@odin.ac.hmc.edu> Message-ID: <20050423024259.B68772@lexi.siliconlandmark.com> References: <52997.83.226.116.53.1114121015.squirrel@webmail.chalmers.se> <20050421220902.GA2960@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.537, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: Debug options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 06:45:01 -0000 On Thu, 21 Apr 2005, Brooks Davis wrote: > On Fri, Apr 22, 2005 at 12:03:35AM +0200, Niklas Sorensson wrote: > >> I was wondering how to turn off the debug options mentioned in /usr/src/UPDATING. >> So far, I only found these kernel options: >> >> options KDB >> options DDB >> options GDB >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options WITNESS_SKIPSPIN >> >> Are there any other options that affect performance? The note mentions >> malloc-debugging flags, but I don't know how to turn it off. > > That's the big stuff in the kernel. For malloc options, see the > malloc(3) manpage. To completely disable the default malloc debugging > options do: > > ln -s 'aj' /etc/malloc.conf May I also suggest tuning(7)? | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 07:52:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D741B16A4CE; Sat, 23 Apr 2005 07:52:26 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A70943D2F; Sat, 23 Apr 2005 07:52:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j3N7qPpQ010743; Sat, 23 Apr 2005 03:52:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j3N7qPYg046137; Sat, 23 Apr 2005 03:52:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 782797306E; Sat, 23 Apr 2005 03:52:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050423075225.782797306E@freebsd-current.sentex.ca> Date: Sat, 23 Apr 2005 03:52:25 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 07:52:27 -0000 TB --- 2005-04-23 06:05:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-04-23 06:05:01 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-04-23 06:05:01 - checking out the source tree TB --- 2005-04-23 06:05:01 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-04-23 06:05:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-04-23 06:11:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-04-23 06:11:41 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-23 06:11:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-04-23 07:26:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-23 07:26:42 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-23 07:26:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Apr 23 07:26:43 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Apr 23 07:47:08 UTC 2005 TB --- 2005-04-23 07:47:08 - generating LINT kernel config TB --- 2005-04-23 07:47:08 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2005-04-23 07:47:08 - /usr/bin/make -B LINT TB --- 2005-04-23 07:47:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-04-23 07:47:08 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-04-23 07:47:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 23 07:47:09 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/i386/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror -fi nstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c In file included from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:51: /tinderbox/CURRENT/i386/i386/src/sys/dev/acpica/acpivar.h:425:1: "ACPI_MAX_THREADS" redefined In file included from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acfreebsd.h:128, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acenv.h:208, from /tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/acpi.h:126, from /tinderbox/CURRENT/i386/i386/src/sys/dev/acpi_support/acpi_asus.c:50: ./opt_acpi.h:2:1: this is the location of the previous definition *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-04-23 07:52:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-04-23 07:52:25 - ERROR: failed to build lint kernel TB --- 2005-04-23 07:52:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 08:09:47 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4205916A4CE for ; Sat, 23 Apr 2005 08:09:47 +0000 (GMT) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB22243D31 for ; Sat, 23 Apr 2005 08:09:46 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 42650A3B0010749E; Sat, 23 Apr 2005 10:09:45 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Sat, 23 Apr 2005 10:09:41 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVHPRvXPQgKmmOvTWmFZWPqKX1DMAAm6p8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: RE: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 08:09:47 -0000 Here are some further observations and speculations. On a newly booted system, this is what happens: 1. Start a "dd if=/dev/zero of=/usr/test bs=128k". 2. While looking at 'top', "Inact" grows and "Free" shrinks. 3. Once "Free" has bottomed out, "Inact" stops growing (naturally). 4. 'dd' continues to put a load on the VM system, eventually forcing most processes to be swapped out (illustrated by the "RES" column showing a very low number for all but a few processes). This takes 30-60 seconds after "Free" has bottomed out on my machine. 5. At this point the machine is mostly useless because it can take several minutes to run a simple 'ls'. 6. After a little while in this useless state the machine becomes so unresponsive that it no longer accepts any input, not even a CTRL-C to end the 'dd' process. Breaking into DDB and killing 'dd' from there works though. I tested this again this morning on a system compiled from sources dated 2005.04.23.05.10.00 (just after the commit to kern_exit.c by David Xu), but the behavior seems to be mostly the same. I did not manage to get it to completely lock up though, but I only tested it once on my UP server. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 09:50:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB3D216A4CE for ; Sat, 23 Apr 2005 09:50:33 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2822543D5F for ; Sat, 23 Apr 2005 09:50:33 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DPHHS-000GdD-J4; Sat, 23 Apr 2005 12:50:30 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Doug White In-Reply-To: Message from Doug White <20050422200953.N10333@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Apr 2005 12:50:30 +0300 From: Danny Braniss Message-ID: cc: current@freebsd.org Subject: Re: diskless/unionfs panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 09:50:33 -0000 > On Fri, 22 Apr 2005, Danny Braniss wrote: > > > hi, > > after much debugging, it seems that the main problem with unionfs is > > that if it's called early in the boot process it will panic the kernel: > > > > trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xffffffff8038e3f5 > > stack pointer = 0x10:0xffffffffb1eac7b0 > > frame pointer = 0x10:0xffffffffb1eac7e0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 213 (sh) > > [thread pid 213 tid 100066 ] > > Stopped at _mtx_lock_flags+0x35: cmpq $0x80779d40,0(%rdi) > > unintialized mutex, probably, although it looks like it'd be the vm page > queue mutex which should be init'd by then. > > Is this -CURRENT? yes, cvs'ed a few days ago (but the problem is not new). > > > db> tr > > Tracing pid 213 tid 100066 td 0xffffff007b9b1000 > > _mtx_lock_flags() at _mtx_lock_flags+0x35 > > exec_map_first_page() at exec_map_first_page+0x60 > > If you have a debug kernel for this around, load it into gdb and 'disass > exec_map_first_page' and look around offset 96 to see if its referencing a > mutex (mtx) near there. arghh, gdb, is there a quick guide for this? im almost there, but can't sync speed (the console is at 38400). > > > kern_execve() at kern_execve+0x2a0 > > execve() at execve+0x5d > > syscall() at syscall+0x4ab > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090630c, rsp = > > 0x7fffffffcbf8, rbp = 0 --- > > > > doing the unionfs stuff sometime later - after the single user prompt - seems > > do be ok. > > > > another thing, there are some LOR caused by the unionfs & md: > > extarct of rc.d/initdiskless: > > > > if [ -e /conf/union ]; then > > if ! sysctl vfs.uniondebug >/dev/null 2>&1; then > > echo Loading unionfs > > kldload unionfs > > fi > > echo Doing UNIONFS > > mount_md 4096 /conf/etc > > chmod 755 /conf/etc > > mount_unionfs /conf/etc /etc > > ls -R /etc > /dev/null > > touch /etc/.sentinel > > md_created_etc=created > > fi > > ... > > > > Loading unionfs > > lock order reversal > > 1st 0xffffff007c3b00f0 system map (system map) @ /r+d/6.0/src/sys/vm/vm_map.c: > > 1100 > > 2nd 0xffffff00623d8620 vm object (standard object) @ > > /r+d/6.0/src/sys/vm/vm_map.c:897 > > KDB: stack backtrace: > > witness_checkorder() at witness_checkorder+0x5f1 > > _mtx_lock_flags() at _mtx_lock_flags+0x4a > > vm_map_insert() at vm_map_insert+0x115 > > vm_map_find() at vm_map_find+0x9d > > link_elf_load_file() at link_elf_load_file+0x811 > > linker_load_module() at linker_load_module+0x50e > > kldload() at kldload+0xc3 > > syscall() at syscall+0x4ab > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067950c, rsp = > > 0x7fffffffedf8, rbp = 0x7fffffffee68 --- > > > > Doing UNIONFS > > lock order reversal > > 1st 0xffffffff80892040 vm page queue mutex (vm page queue mutex) @ > > /r+d/6.0/src/sys/kern/vfs_bio.c:1485 > > 2nd 0xffffff0061dc98b0 vnode interlock (vnode interlock) @ > > /r+d/6.0/src/sys/kern/vfs_subr.c:1992 > > KDB: stack backtrace: > > witness_checkorder() at witness_checkorder+0x5f1 > > _mtx_lock_flags() at _mtx_lock_flags+0x4a > > vdrop() at vdrop+0x31 > > vm_page_remove() at vm_page_remove+0x126 > > vm_page_free_toq() at vm_page_free_toq+0x61 > > vm_page_free() at vm_page_free+0x1e > > vfs_vmio_release() at vfs_vmio_release+0x18f > > brelse() at brelse+0x792 > > ffs_mount() at ffs_mount+0x121b > > vfs_donmount() at vfs_donmount+0xaa3 > > kernel_mount() at kernel_mount+0xaf > > ffs_cmount() at ffs_cmount+0x92 > > mount() at mount+0x132 > > syscall() at syscall+0x1fb > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (21, FreeBSD ELF64, mount), rip = 0x80067e68c, rsp = > > 0x7fffffffdf98, rbp = 0x7fffffffea58 --- > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 10:19:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD4D216A4CE for ; Sat, 23 Apr 2005 10:19:30 +0000 (GMT) Received: from mail.sorbs.net (news.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id D668C43D2F for ; Sat, 23 Apr 2005 10:19:29 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFE00K02A14J8@nemesis.sorbs.net> for freebsd-current@freebsd.org; Sat, 23 Apr 2005 20:19:53 +1000 (EST) Date: Sat, 23 Apr 2005 20:18:13 +1000 From: Matthew Sullivan In-reply-to: <20050423020305.I68772@lexi.siliconlandmark.com> To: Andre Guibert de Bruet Message-id: <426A20E5.5020604@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms030507070805050308090407; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <4269C251.8070504@uq.edu.au> <20050423020305.I68772@lexi.siliconlandmark.com> cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 10:19:30 -0000 This is a cryptographically signed message in MIME format. --------------ms030507070805050308090407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Guibert de Bruet wrote: > > On Sat, 23 Apr 2005, Matthew Sullivan wrote: > >> Andre Guibert de Bruet wrote: >> >>> On Thu, 21 Apr 2005, Matthew Sullivan wrote: >>> >>>> I've been reading about problems with HP/Compaq's regarding >>>> launching of second CPUs on SMP systems. >>>> >>>> I've been through the BIOS settings and there seems to be no >>>> settings to change the APCI table etc.... >>>> >>>> Now one thing that does seem common, when I have BIOS's with MP >>>> table version set to 1.4 FreeBSD doesn't report the second CPU >>>> being launched (even though it is seen in the acpidump).... When I >>>> set the BIOS to version 1.2 of the MP table the second CPU is >>>> reported and launched. >>>> >>>> Now the Compaq DL380's I have done seem to have the ability to set >>>> 1.4 or 1.2 of the table ... mptable reports 1.4... (below) >>>> >>>> Any suggestions on how to launch the second CPU...? >>> >>> >>> Make a boot -v from this machine available. >> >> >> http://scorpion.sorbs.net/dmesg.txt > > > The lack of the following seems to indicate that you do not have > "device apic" enabled in your kernel config (You need "options SMP" as > well to get FreeBSD to do more than just recognize both CPUs): > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: > > Please share your config and the steps that you are taking to build > your kernel. /usr/src/sys/i386/conf/SCORPION has been copied to: http://scorpion.sorbs.net/SCORPION /etc/make.conf contains 'KERNCONF=SCORPION' then I follow the instructions in the Makefile.... cd /usr/src make buildworld make buildkernel make installkernel reboot mergemaster -p make installworld mergemaster reboot Nothing that I can see I'm doing wrong.... (before I read the man page for make.conf I was using KERNCONF=SCORPION in the appropriate places on the command line) -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms030507070805050308090407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMzEwMTgxM1owIwYJKoZIhvcNAQkEMRYEFEEaakBe1Cyf6Tzq Q5SuXbara39RMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQGnIIPgX/dy5KvTUC7vDvKvuK+N2raPwASX3EImQpSJ+wZYzOVpGMjU3K/gFvJ/cW3Ly 5jUYL3ob8o0Gyu+S+agAAAAAAAA= --------------ms030507070805050308090407-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 15:28:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B762616A4CE; Fri, 22 Apr 2005 15:28:20 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 520F843D55; Fri, 22 Apr 2005 15:28:20 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j3MFSFc5062091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 22 Apr 2005 11:28:18 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j3MFSFv5062088; Fri, 22 Apr 2005 11:28:15 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.6159.521697.442481@khavrinen.csail.mit.edu> Date: Fri, 22 Apr 2005 11:28:15 -0400 To: Brian Fundakowski Feldman In-Reply-To: <20050422150835.GM1157@green.homeunix.org> References: <20050419160900.GB12287@stack.nl> <20050419161616.GF1157@green.homeunix.org> <20050419204723.GG1157@green.homeunix.org> <20050420140409.GA77731@stack.nl> <20050420142448.GH1157@green.homeunix.org> <20050420143842.GB77731@stack.nl> <20050420152038.GI1157@green.homeunix.org> <20050420153528.GC77731@stack.nl> <20050420155233.GJ1157@green.homeunix.org> <16998.37222.529748.205885@khavrinen.csail.mit.edu> <20050422150835.GM1157@green.homeunix.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 22 Apr 2005 11:28:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.83/848/Thu Apr 21 15:37:33 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Sat, 23 Apr 2005 11:58:07 +0000 cc: freebsd-hackers@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 15:28:20 -0000 < said: > Can you find any evidence that it's acceptable to interleave multiple > writers that are doing O_APPEND? At best, to do what you're asking, > they could be kept from being interleaved from the context of one > specific NFS client host... As far as POSIX goes, the standard says that applications are expected to handle serialization. It makes no exception for O_APPEND. -GAWollman From owner-freebsd-current@FreeBSD.ORG Fri Apr 22 23:37:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4A3A16A4CE for ; Fri, 22 Apr 2005 23:37:08 +0000 (GMT) Received: from e.0x20.net (gw.0x20.net [217.69.68.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 268FF43D3F for ; Fri, 22 Apr 2005 23:37:08 +0000 (GMT) (envelope-from lars@0x20.net) Received: from bart.bsd-geek.de ([IPv6:2001:6f8:1336:0:20a:e4ff:fe24:403d]) (authenticated bits=128) by e.0x20.net (8.13.3/8.13.1/Submit) with ESMTP id j3MNb24k082495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Apr 2005 01:37:06 +0200 (CEST) (envelope-from lars@bsd-geek.de) Received: from bart.bsd-geek.de (localhost.bsd-geek.de [127.0.0.1]) by bart.bsd-geek.de (8.13.3/8.13.1) with ESMTP id j3MNb1MM003938; Sat, 23 Apr 2005 01:37:02 +0200 (CEST) (envelope-from lars@bart.bsd-geek.de) Received: (from lars@localhost) by bart.bsd-geek.de (8.13.3/8.13.1/Submit) id j3MNb0D6003937; Sat, 23 Apr 2005 01:37:00 +0200 (CEST) (envelope-from lars) Date: Sat, 23 Apr 2005 01:36:58 +0200 From: Lars Engels To: Sebastian Schulze Struchtrup Message-ID: <20050422233658.GA92599@bart.bsd-geek.de> References: <200504211606.j3LG6gbc007250@peedub.jennejohn.org> <4268E399.6030304@struchtrup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4268E399.6030304@struchtrup.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 23 Apr 2005 11:58:07 +0000 cc: Lars Engels cc: current@freebsd.org Subject: Re: library problems with -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 23:37:08 -0000 On Fri, Apr 22, 2005 at 01:44:25PM +0200, Sebastian Schulze Struchtrup wrote: > Gary Jennejohn wrote: > > > > >It's not in UPDATING, but a change was recently made (can't say exactly > >when) which affects %gs/%fs. If you're using -current then you really > >should watch the commits, too! > > > >You'll have to recompile these ports, I suspect. Interestingly, my old > >gkrellm still runs just fine with a new world from yesterday, but I had > >to reinstall transcode. > > > > > > > > This was introduced by libpthread (and libkse, I think) using > i386_(get/set)_(gs/fs)base in libc > The old libc.5 doesn't have this functions implemented and is no longer > rebuild as we're using libc.6 now. > This affects all ports which are still using libc.5 and libpthread/libkse. > The easiest approach is probably to rebuild all your ports so that they > are using libc.6 > Anyway, libc.5 without pthreads/kse works fine on my system. > > Maybe this should be placed into src/UPDATING? > Would have saved me a lot of work :) Anyway, I think I recompiled are the necessary ports and the system's running fine again :) Thanks for your help! From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 12:16:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4BAF16A4CF for ; Sat, 23 Apr 2005 12:16:37 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 893B743D46 for ; Sat, 23 Apr 2005 12:16:37 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DPJYq-000Inb-NE for freebsd-current@freebsd.org; Sat, 23 Apr 2005 15:16:36 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Apr 2005 15:16:36 +0300 From: Danny Braniss Message-ID: Subject: serial console problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 12:16:38 -0000 the receiver part of the serial console seems to be somewhat problematic, i have to type almost every character more than once to be acccepted, making debugging with kgdb impossible. BTW, 5.4 works fine, so it's not a hardware problem, nor parity/speed/start-stop bits. danny From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 12:29:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8000316A4CE for ; Sat, 23 Apr 2005 12:29:10 +0000 (GMT) Received: from mail.sorbs.net (mail.sorbs.net [203.15.51.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CBE43D2D for ; Sat, 23 Apr 2005 12:29:09 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from [10.200.254.98] by nemesis.sorbs.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFE00K06G18J8@nemesis.sorbs.net> for freebsd-current@freebsd.org; Sat, 23 Apr 2005 22:29:33 +1000 (EST) Date: Sat, 23 Apr 2005 22:27:53 +1000 From: Matthew Sullivan In-reply-to: <42663EA1.3020409@uq.edu.au> To: freebsd-current@freebsd.org Message-id: <426A3F49.6090203@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms080202010405040106090400; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 References: <426426AE.2060406@uq.edu.au> <20050420084413.GA27304@walton.maths.tcd.ie> <42663EA1.3020409@uq.edu.au> Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 12:29:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080202010405040106090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Matthew Sullivan wrote: > I'm going to post this back to the list as Marko was also helping me get > to the bottom of it... > > David Malone wrote: > >> On Tue, Apr 19, 2005 at 07:29:18AM +1000, Matthew Sullivan wrote: >> >> >>> Any reason why FreeBSD 5.2.1+ and 5.3-p9 set DF on all packets? >>> >> >> >> It is usual to do this to do path MTU discovery with TCP. I don't >> know what the situation with the packets that the VPN sends is. > Ok well thanks to Andrew @ Supernews and a lot of debugging it appears there is a bug.... sys/netinet/ip_icmp.c: line 440 if (!mtu) mtu = ip_next_mtu(mtu, 1); Problem is ip_next_mtu will always return 0 when called with (0, 1) ... so following that with: if (mtu >= max(296, (tcp_minmss + sizeof(struct tcpiphdr)))) tcp_hc_updatemtu(&inc, mtu); and nothing gets changed.... hence why it fails. Apparently the gateway should be suggesting a MTU value for use.... the gateway is also FreeBSD 5.3 so something needs fixing .. :-/ Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms080202010405040106090400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDQyMzEyMjc1M1owIwYJKoZIhvcNAQkEMRYEFI/9e5MFw1OVhtd8 0ESWKfoM9ZmhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQG6ngvNgl7nukszVkn0oxNJzvvRiDa7Cnac/dbaSCHHLXS0gG2RLyy6m/o7XM+spWJpG lIX6b/UhUdaXXMRByuEAAAAAAAA= --------------ms080202010405040106090400-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 12:32:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEF3A16A4CF for ; Sat, 23 Apr 2005 12:32:22 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8ED343D48 for ; Sat, 23 Apr 2005 12:32:22 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3NCWJjQ043941 for ; Sat, 23 Apr 2005 12:32:21 GMT (envelope-from davidxu@freebsd.org) Message-ID: <426A405C.3040401@freebsd.org> Date: Sat, 23 Apr 2005 20:32:28 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050402 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: rescue truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 12:32:23 -0000 Is there anyone working on truss ? it is no longer work well with threaded process, I may work on it if there is no one. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 14:41:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2C0A16A4CE for ; Sat, 23 Apr 2005 14:41:21 +0000 (GMT) Received: from hq.sectorb.msk.ru (petaflop.b.gz.ru [217.67.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1626943D39 for ; Sat, 23 Apr 2005 14:41:21 +0000 (GMT) (envelope-from chinhngt@sectorb.msk.ru) Received: from it.hackers (it.hackers [172.16.37.1]) by hq.sectorb.msk.ru (Postfix) with ESMTP id 9DED618C0; Sat, 23 Apr 2005 18:41:18 +0400 (MSD) Date: Sat, 23 Apr 2005 18:43:00 +0400 (MSD) From: Nguyen Tam Chinh X-X-Sender: chinhngt@it.hackers To: Eric Anholt In-Reply-To: <1114212379.955.15.camel@leguin> Message-ID: <20050423184110.O37477@it.hackers> References: <20050423005715.G16129@it.hackers> <1114212379.955.15.camel@leguin> X-Operating-System: FreeBSD 5.3-STABLE Keywords: 216091683 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@freebsd.org Subject: Re: mgadrm fail in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 14:41:21 -0000 On Fri, 22 Apr 2005, Eric Anholt wrote: > On Sat, 2005-04-23 at 01:01 +0400, Nguyen Tam Chinh wrote: >> Hello All, >> I've just compiled -CURRENT (cvsup some hours ago) and the magdrm seemed >> to be fail. >> Last week's -CURRENT build was okay. > > Do you have device drm in your kernel? > Did you do a clean build? > Aha, I checked the config/NOTES and noticed that the new line: device drm Thank you :) > There's no real reason to be building the drm into the kernel that I can > see, as it's automatically loaded for you by the X Server. > > -- > Eric Anholt eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > ----- With best regards, | The Power to Serve Nguyen Tam Chinh | http://www.FreeBSD.org Loc: sp.cs.msu.ru | From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 15:09:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D1A716A4CE for ; Sat, 23 Apr 2005 15:09:09 +0000 (GMT) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82C8A43D39 for ; Sat, 23 Apr 2005 15:09:08 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id j3NFA5hE016451; Sat, 23 Apr 2005 17:10:05 +0200 (MEST) Message-ID: <426A64FD.5090002@fer.hr> Date: Sat, 23 Apr 2005 17:08:45 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson , current@freebsd.org References: <426925C7.3030004@samsco.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Serious I/O problems (bad performance and live-lock) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 15:09:09 -0000 Daniel Eriksson wrote: > According to 'top', the dd process spend most of its time in "wdrain" state. This very probably is not the same problem, but maybe it's connected - something in the GEOM path, maybe? http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2004-October/008512.html From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 17:18:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C87ED16A4CE; Sat, 23 Apr 2005 17:18:52 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 605DD43D2D; Sat, 23 Apr 2005 17:18:52 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3NHIpe5031891; Sat, 23 Apr 2005 12:18:51 -0500 (CDT) (envelope-from dan) Date: Sat, 23 Apr 2005 12:18:51 -0500 From: Dan Nelson To: David Xu Message-ID: <20050423171851.GA67026@dan.emsphone.com> References: <426A405C.3040401@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426A405C.3040401@freebsd.org> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: current@freebsd.org Subject: Re: rescue truss X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 17:18:52 -0000 In the last episode (Apr 23), David Xu said: > Is there anyone working on truss ? it is no longer work well with > threaded process, I may work on it if there is no one. If you (or anyone else) does, please take a look at bin/52190 for patches that decode more syscalls and clean up printing of flags and bitfields. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 18:51:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77AFA16A4CE for ; Sat, 23 Apr 2005 18:51:20 +0000 (GMT) Received: from lakermmtao10.cox.net (lakermmtao10.cox.net [68.230.240.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C1D43D49 for ; Sat, 23 Apr 2005 18:51:19 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050423185117.TYQS7787.lakermmtao10.cox.net@dolphin.local.net>; Sat, 23 Apr 2005 14:51:17 -0400 Received: from dolphin.local.net (conrads@localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j3NIpDG5094606; Sat, 23 Apr 2005 13:51:17 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sat, 23 Apr 2005 13:51:12 -0500 From: "Conrad J. Sabatier" To: Andre Guibert de Bruet Message-ID: <20050423135112.63c74617@dolphin.local.net> In-Reply-To: <20050423023605.A68772@lexi.siliconlandmark.com> References: <20050418232455.2d530890@dolphin.local.net> <5265.1113888748@critter.freebsd.dk> <20050419130048.6e545269@dolphin.local.net> <20050423023605.A68772@lexi.siliconlandmark.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Re: FreeBSD MIDI (Was: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 18:51:20 -0000 On Sat, 23 Apr 2005 02:42:10 -0400 (EDT), Andre Guibert de Bruet wrote: > > On Tue, 19 Apr 2005, Conrad J. Sabatier wrote: > > > It looks like MIDI is really starting to come together, though. I > > now have a loadable kernel module "midi.ko", with support for cmi > > and emu10k1 cards. I've already seen a report from someone on the > > multimedia list who actually got this to work with his card > > and external MIDI synth. Hopefully, we can get support for more > > cards included soon. :-) > > > > We'll keep the current list informed as to further developments. > > I would love to get my Yamaha synth working with FreeBSD! What state > are these patches in? Is this something that we could expect for > 6.0-rel? Well, I haven't been able to actually run the driver through any tests, yet, as my soundcard is not (yet) one of the supported ones. But it does compile OK, and as I mentioned before, I know of at least one person who reported successful MIDI playback via his external MIDI synth keyboard. I'm hoping Mat will be able to add es137x support soon, so I can actually see how well this thing will work. I'm fairly optimistic at this point; it's just a matter of copying/adapting the patches for other cards into the es137x files. I couldn't tell you for sure which FreeBSD release will be the one to announce the addition of MIDI, but I do think 6.0 could very well possibly be it, with additional backpatching into 5.x-STABLE as well. By the way, what kind of Yamaha synth do you have? Mine is an SO3. I can hardly wait to be able to use it under FreeBSD! -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 20:01:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E06216A4CE for ; Sat, 23 Apr 2005 20:01:36 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFB0343D3F for ; Sat, 23 Apr 2005 20:01:35 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3NK1Ul9001769; Sat, 23 Apr 2005 16:01:30 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3NK1UYk001766; Sat, 23 Apr 2005 16:01:30 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 16:01:30 -0400 (EDT) From: Andre Guibert de Bruet To: Matthew Sullivan In-Reply-To: <426A20E5.5020604@uq.edu.au> Message-ID: <20050423152223.Q68772@lexi.siliconlandmark.com> References: <4267A1CF.3080903@uq.edu.au> <20050422190208.M68772@lexi.siliconlandmark.com> <20050423020305.I68772@lexi.siliconlandmark.com> <426A20E5.5020604@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.538, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org Subject: Re: SMP on Compaq DL380 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 20:01:36 -0000 On Sat, 23 Apr 2005, Matthew Sullivan wrote: > Andre Guibert de Bruet wrote: >> On Sat, 23 Apr 2005, Matthew Sullivan wrote: >>> Andre Guibert de Bruet wrote: >>>> On Thu, 21 Apr 2005, Matthew Sullivan wrote: >>>> >>>>> I've been reading about problems with HP/Compaq's regarding launching of >>>>> second CPUs on SMP systems. >>>>> >>>>> I've been through the BIOS settings and there seems to be no settings to >>>>> change the APCI table etc.... >>>>> >>>>> Now one thing that does seem common, when I have BIOS's with MP table >>>>> version set to 1.4 FreeBSD doesn't report the second CPU being launched >>>>> (even though it is seen in the acpidump).... When I set the BIOS to >>>>> version 1.2 of the MP table the second CPU is reported and launched. >>>>> >>>>> Now the Compaq DL380's I have done seem to have the ability to set 1.4 >>>>> or 1.2 of the table ... mptable reports 1.4... (below) >>>>> >>>>> Any suggestions on how to launch the second CPU...? >>>> >>>> Make a boot -v from this machine available. >>> >>> http://scorpion.sorbs.net/dmesg.txt >> >> The lack of the following seems to indicate that you do not have "device >> apic" enabled in your kernel config (You need "options SMP" as well to get >> FreeBSD to do more than just recognize both CPUs): >> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: >> >> Please share your config and the steps that you are taking to build your >> kernel. > > /usr/src/sys/i386/conf/SCORPION has been copied to: > http://scorpion.sorbs.net/SCORPION > > /etc/make.conf contains 'KERNCONF=SCORPION' > then I follow the instructions in the Makefile.... > > cd /usr/src > make buildworld > make buildkernel > make installkernel > reboot > mergemaster -p > make installworld > mergemaster > reboot > > (before I read the man page for make.conf I was using KERNCONF=SCORPION in > the appropriate places on the command line) The dmesg shows that you compiled the kernel using this config file anyway. All is good so far. Processors: APIC ID Version State Family Model Step Flags 0 0x10 BSP, usable 6 2 1 0x0381 0 0x10 AP, usable 6 8 6 0x383fbff The APIC IDs here are the same. The flags on the would-be AP are what I would expect for a recent i686. The BSP barely qualify it to be a gen-1 Pentium. I wouldn't trust any of the values being reported. Could you obtain the real identity of these CPUs and confirm that they're not mismatched? The easy way of doing this if your BIOS doesn't post this information is using a Knoppix LiveCD and doing a cat /proc/cpuinfo. If both CPUs are reporting the same ID, I can see how we're not launching the second proc; We assume that ID 0 is the BSP and additional processors have different APIC IDs. Is something really borked here? Yep! Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 20:32:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C661F16A4CE for ; Sat, 23 Apr 2005 20:32:11 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F9C443D1F for ; Sat, 23 Apr 2005 20:32:09 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 24620 invoked by uid 89); 23 Apr 2005 20:32:07 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Apr 2005 20:32:07 -0000 Received: (qmail 24598 invoked by uid 89); 23 Apr 2005 20:32:07 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Apr 2005 20:32:07 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j3NKW6w6048089; Sat, 23 Apr 2005 16:32:07 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Danny Braniss In-Reply-To: References: Content-Type: text/plain Message-Id: <1114288326.17300.4784.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 23 Apr 2005 16:32:06 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: serial console problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 20:32:11 -0000 On Sat, 2005-04-23 at 08:16, Danny Braniss wrote: > the receiver part of the serial console seems to be somewhat problematic, > i have to type almost every character more than once to be acccepted, making > debugging with kgdb impossible. BTW, 5.4 works fine, so it's not a hardware > problem, nor parity/speed/start-stop bits. > > danny Could you file a bug report including your configuration, dmesg and any changed boot flags / device hints? I plan to address another serial debugging problem in the next 7-14 days and may as well take a look at your problem while I am at it. Thanks Stephan From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 20:41:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73AE816A4CE for ; Sat, 23 Apr 2005 20:41:09 +0000 (GMT) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1997B43D3F for ; Sat, 23 Apr 2005 20:41:09 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) j3NKei0u002003; Sat, 23 Apr 2005 16:40:44 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j3NKeiZs002000; Sat, 23 Apr 2005 16:40:44 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sat, 23 Apr 2005 16:40:44 -0400 (EDT) From: Andre Guibert de Bruet To: "Conrad J. Sabatier" In-Reply-To: <20050423135112.63c74617@dolphin.local.net> Message-ID: <20050423161839.P68772@lexi.siliconlandmark.com> References: <20050418232455.2d530890@dolphin.local.net> <5265.1113888748@critter.freebsd.dk> <20050423023605.A68772@lexi.siliconlandmark.com> <20050423135112.63c74617@dolphin.local.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.538, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com cc: freebsd-current@freebsd.org cc: Mathew Kanner Subject: Re: FreeBSD MIDI (Was: Re: What happened to the "d_maj" member of "struct cdevsw" in CURRENT?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 20:41:09 -0000 On Sat, 23 Apr 2005, Conrad J. Sabatier wrote: > Well, I haven't been able to actually run the driver through any tests, > yet, as my soundcard is not (yet) one of the supported ones. But it > does compile OK, and as I mentioned before, I know of at least one > person who reported successful MIDI playback via his external MIDI synth > keyboard. > > I'm hoping Mat will be able to add es137x support soon, so I can > actually see how well this thing will work. I'm fairly optimistic at > this point; it's just a matter of copying/adapting the patches for other > cards into the es137x files. > > I couldn't tell you for sure which FreeBSD release will be the one to > announce the addition of MIDI, but I do think 6.0 could very well > possibly be it, with additional backpatching into 5.x-STABLE as well. > > By the way, what kind of Yamaha synth do you have? Mine is an SO3. I > can hardly wait to be able to use it under FreeBSD! I have an emu10k1, so I guess I could give it a spin. Any ideas for the whereabout of these patches? My synth is an S08. Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ >