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: