From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 00:23:07 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A729516A4AB; Sun, 25 Jun 2006 00:23:07 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F88043D7B; Sun, 25 Jun 2006 00:23:01 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id 55116290C2B; Sat, 24 Jun 2006 21:22:56 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 11078-09; Sat, 24 Jun 2006 21:23:00 -0300 (ADT) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id C48DB290C29; Sat, 24 Jun 2006 21:22:55 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id BE59638E8A; Sat, 24 Jun 2006 21:23:04 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id B790D3609C; Sat, 24 Jun 2006 21:23:04 -0300 (ADT) Date: Sat, 24 Jun 2006 21:23:04 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freeBSD.org In-Reply-To: <20060624211229.X1114@ganymede.hub.org> Message-ID: <20060624212108.C1114@ganymede.hub.org> References: <20060624211229.X1114@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 00:23:07 -0000 On Sat, 24 Jun 2006, Marc G. Fournier wrote: > > 'k, looks like I'm going to have to back this out ... just upgraded another > server to 6.x, CVSup latest -STABLE, built, installed, rebooted ... up fine > ... > > Running a single 'rsync' to copy files from another server over, it has > crashed twice in a row so far ... > > I'm enabling dumpdev right now, and will see if I can a core dump out of it, > but, so far, there is nothing being reported in /var/log/messages to indicate > a problem ... > > Does anyone know of any problems with current source tree that I should > avoid? And, if so, can someone recommend a "stable date" to CVSup in and > try? This server isn't production yet, and I'm not panic'd right now to make > it so (basically, I've got a couple of days if I need it) ... Just found this in my /var/log/messages file after the last reboot to enable savecore/dumpdev: Jun 25 00:19:59 jupiter kernel: ACPI-0356: *** Error: Region SystemIO(1) has no handler Jun 25 00:19:59 jupiter kernel: ACPI-1304: *** Error: Method execution failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST Jun 25 00:19:59 jupiter kernel: ACPI-0239: *** Error: Method execution failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST For those on the -acpi list, this machine is an Intel Dual-PIII motherboard ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 00:29:39 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD95E16A492; Sun, 25 Jun 2006 00:29:39 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8503A43D55; Sun, 25 Jun 2006 00:29:38 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id E23E1290C2B; Sat, 24 Jun 2006 21:29:32 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 17690-02; Sat, 24 Jun 2006 21:29:37 -0300 (ADT) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id 61516290C29; Sat, 24 Jun 2006 21:29:32 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id A6F7D38000; Sat, 24 Jun 2006 21:29:41 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 701C43609C; Sat, 24 Jun 2006 21:29:41 -0300 (ADT) Date: Sat, 24 Jun 2006 21:29:40 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freeBSD.org In-Reply-To: <20060624212108.C1114@ganymede.hub.org> Message-ID: <20060624212742.K1114@ganymede.hub.org> References: <20060624211229.X1114@ganymede.hub.org> <20060624212108.C1114@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 00:29:39 -0000 On Sat, 24 Jun 2006, Marc G. Fournier wrote: > On Sat, 24 Jun 2006, Marc G. Fournier wrote: > >> >> 'k, looks like I'm going to have to back this out ... just upgraded another >> server to 6.x, CVSup latest -STABLE, built, installed, rebooted ... up fine >> ... >> >> Running a single 'rsync' to copy files from another server over, it has >> crashed twice in a row so far ... >> >> I'm enabling dumpdev right now, and will see if I can a core dump out of >> it, but, so far, there is nothing being reported in /var/log/messages to >> indicate a problem ... >> >> Does anyone know of any problems with current source tree that I should >> avoid? And, if so, can someone recommend a "stable date" to CVSup in and >> try? This server isn't production yet, and I'm not panic'd right now to >> make it so (basically, I've got a couple of days if I need it) ... > > > Just found this in my /var/log/messages file after the last reboot to enable > savecore/dumpdev: > > Jun 25 00:19:59 jupiter kernel: ACPI-0356: *** Error: Region SystemIO(1) has > no handler > Jun 25 00:19:59 jupiter kernel: ACPI-1304: *** Error: Method execution failed > [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST > Jun 25 00:19:59 jupiter kernel: ACPI-0239: *** Error: Method execution failed > [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST > > For those on the -acpi list, this machine is an Intel Dual-PIII motherboard > ... 'k, I'm starting to get the impression that FreeBSD 6.x is evil ... at least as far as Dual-PIII servers are concerned ... on a machine that, like the other Dual-PIII, I've only ever had hard drive issues with, and then rarely, I just upgraded to FreeBSD 6.x yesterday, and am trying to rsync a bunch of files across, and am getting: ========= doing nssci.net from uranus Bad system call (core dumped) rsync: connection unexpectedly closed (4610 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(472) [sender=2.6.8] doing ns2.earthtecinc.com from uranus rsync: connection unexpectedly closed (1030362 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(443) ========= I've *never* seen rsync give a problem before, on any of my servers, now I'm getting core dumps? Am back tracking to RELENG_6_1 right now, see if that helps ... :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 01:25:56 2006 Return-Path: X-Original-To: freebsd-acpi@freeBSD.org Delivered-To: freebsd-acpi@freeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EEAE16A4D0; Sun, 25 Jun 2006 01:25:56 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3605643D45; Sun, 25 Jun 2006 01:25:56 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net [207.115.4.147]) by ylpvm43.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k5P1Pw4O005327; Sat, 24 Jun 2006 21:25:58 -0400 X-ORBL: [71.139.104.128] Received: from [10.0.5.51] (ppp-71-139-104-128.dsl.snfc21.pacbell.net [71.139.104.128]) by pimout7-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k5P1PrlY162626; Sat, 24 Jun 2006 21:25:53 -0400 Message-ID: <449DE5AE.9000708@root.org> Date: Sat, 24 Jun 2006 18:23:58 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: "Marc G. Fournier" References: <20060624211229.X1114@ganymede.hub.org> <20060624212108.C1114@ganymede.hub.org> In-Reply-To: <20060624212108.C1114@ganymede.hub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 01:25:56 -0000 Marc G. Fournier wrote: > On Sat, 24 Jun 2006, Marc G. Fournier wrote: > >> >> 'k, looks like I'm going to have to back this out ... just upgraded >> another server to 6.x, CVSup latest -STABLE, built, installed, >> rebooted ... up fine ... >> >> Running a single 'rsync' to copy files from another server over, it >> has crashed twice in a row so far ... >> >> I'm enabling dumpdev right now, and will see if I can a core dump out >> of it, but, so far, there is nothing being reported in >> /var/log/messages to indicate a problem ... >> >> Does anyone know of any problems with current source tree that I >> should avoid? And, if so, can someone recommend a "stable date" to >> CVSup in and try? This server isn't production yet, and I'm not >> panic'd right now to make it so (basically, I've got a couple of days >> if I need it) ... > > > Just found this in my /var/log/messages file after the last reboot to > enable savecore/dumpdev: > > Jun 25 00:19:59 jupiter kernel: ACPI-0356: *** Error: Region SystemIO(1) > has no handler > Jun 25 00:19:59 jupiter kernel: ACPI-1304: *** Error: Method execution > failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST > Jun 25 00:19:59 jupiter kernel: ACPI-0239: *** Error: Method execution > failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST > > For those on the -acpi list, this machine is an Intel Dual-PIII > motherboard ... What changes if acpi is disabled? Are you running a custom AML? The SystemIO thing seems troubling. Is there an earlier message that explains why? These are new messages? Have you passed the memtest x86 CD? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 02:12:27 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D3A216A4A0; Sun, 25 Jun 2006 02:12:27 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C16E43D5F; Sun, 25 Jun 2006 02:12:22 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (mx1.hub.org [200.46.208.251]) by hub.org (Postfix) with ESMTP id 5610D290C29; Sat, 24 Jun 2006 23:12:16 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 59682-02; Sat, 24 Jun 2006 23:12:21 -0300 (ADT) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id 35069290C1E; Sat, 24 Jun 2006 23:12:15 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 207F03ECEA; Sat, 24 Jun 2006 23:12:25 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id DC0D133DF1; Sat, 24 Jun 2006 23:12:25 -0300 (ADT) Date: Sat, 24 Jun 2006 23:12:25 -0300 (ADT) From: "Marc G. Fournier" To: Nate Lawson In-Reply-To: <449DE5AE.9000708@root.org> Message-ID: <20060624230418.P1114@ganymede.hub.org> References: <20060624211229.X1114@ganymede.hub.org> <20060624212108.C1114@ganymede.hub.org> <449DE5AE.9000708@root.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1759118603-1151201545=:1114" Cc: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 02:12:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1759118603-1151201545=:1114 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 24 Jun 2006, Nate Lawson wrote: > Marc G. Fournier wrote: >> On Sat, 24 Jun 2006, Marc G. Fournier wrote: >> >>> >>> 'k, looks like I'm going to have to back this out ... just upgraded >>> another server to 6.x, CVSup latest -STABLE, built, installed, rebooted >>> ... up fine ... >>> >>> Running a single 'rsync' to copy files from another server over, it has >>> crashed twice in a row so far ... >>> >>> I'm enabling dumpdev right now, and will see if I can a core dump out of >>> it, but, so far, there is nothing being reported in /var/log/messages to >>> indicate a problem ... >>> >>> Does anyone know of any problems with current source tree that I should >>> avoid? And, if so, can someone recommend a "stable date" to CVSup in and >>> try? This server isn't production yet, and I'm not panic'd right now to >>> make it so (basically, I've got a couple of days if I need it) ... >> >> >> Just found this in my /var/log/messages file after the last reboot to >> enable savecore/dumpdev: >> >> Jun 25 00:19:59 jupiter kernel: ACPI-0356: *** Error: Region SystemIO(1) >> has no handler >> Jun 25 00:19:59 jupiter kernel: ACPI-1304: *** Error: Method execution >> failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST >> Jun 25 00:19:59 jupiter kernel: ACPI-0239: *** Error: Method execution >> failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST >> >> For those on the -acpi list, this machine is an Intel Dual-PIII motherboard >> ... > > What changes if acpi is disabled? Are you running a custom AML? 'k, this server is, unfortunately, a remote server, so disabling ACPI isn't something I can easily do ... :( At least not until Monday ... re: custom AML ... stupid question, but what is an AML? :( > The SystemIO thing seems troubling. Is there an earlier message that > explains why? Nothing: Jun 25 00:19:24 jupiter kernel: Trying to mount root from ufs:/dev/da0s1a Jun 25 00:19:24 jupiter savecore: no dumps found Jun 25 00:19:24 jupiter named[381]: starting BIND 9.3.2 -t /var/named -u bind Jun 25 00:19:24 jupiter named[381]: command channel listening on 127.0.0.1#953 Jun 25 00:19:24 jupiter named[381]: zone 0.0.127.IN-ADDR.ARPA/IN: loading master file master/localhost.rev: file not found Jun 25 00:19:24 jupiter named[381]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN: loading master file master/localhost-v6.rev: file not found Jun 25 00:19:24 jupiter named[381]: running Jun 25 00:19:24 jupiter kernel: fxp0: promiscuous mode enabled Jun 25 00:19:59 jupiter kernel: ACPI-0356: *** Error: Region SystemIO(1) has no handler Jun 25 00:19:59 jupiter kernel: ACPI-1304: *** Error: Method execution failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST Jun 25 00:19:59 jupiter kernel: ACPI-0239: *** Error: Method execution failed [\_SB_.LN02._STA] (Node 0xc9071920), AE_NOT_EXIST > These are new messages? Most definitely ... but, I've attached my dmesg.boot, which includes a bunch of ACPI Warnings ... from searching Google, it was my understanding that they are/were benign though ... I get the same Warnings on my other Dual-PIII box, but its a duplicate of this one, so that is to be expected ... > Have you passed the memtest x86 CD? Just as an appendum to this report ... I have rebooted the server using the 6.1-RC1 kernel that was originally installed, before I upgraded to -STABLE, and am now running both an rsync that *so far* hasn't giving me any SegFaults, and am running a 'make buildworld' with a RELENG_6_1 source tree, that also hasn't cause any problems ... in fact, tail of my /var/log/messages shows: # tail /var/log/messages Jun 25 01:23:27 jupiter named[391]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN: loading master file master/localhost-v6.rev: file not found Jun 25 01:23:27 jupiter named[391]: running Jun 25 01:23:27 jupiter kernel: fxp0: promiscuous mode enabled Jun 25 01:24:44 jupiter fsck: /dev/da0s1d: 11 files, 7 used, 63344 free (40 frags, 7913 blocks, 0.1% fragmentation) Jun 25 01:25:47 jupiter fsck: /dev/da0s1e: 191421 files, 833872 used, 688631 free (18623 frags, 83751 blocks, 1.2% fragmentation) Jun 25 01:25:48 jupiter fsck: /dev/da0s1f: Reclaimed: 0 directories, -1 files, -1 fragments Jun 25 01:25:48 jupiter fsck: /dev/da0s1f: 217 files, 817 used, 62535 free (71 frags, 7808 blocks, 0.1% fragmentation) Jun 25 01:31:12 jupiter fsck: /dev/da0s1g: 429378 files, 3425842 used, 60096474 free (6314 frags, 7511270 blocks, 0.0% fragmentation) Jun 25 02:00:00 jupiter kernel: fxp0: promiscuous mode disabled Jun 25 02:00:00 jupiter kernel: fxp0: promiscuous mode enabled jupiter# uptime 2:06AM up 43 mins, 3 users, load averages: 1.38, 1.36, 1.22 jupiter# With -STABLE of today, I couldn't even run a complete cvsup without it giving me an error: -------- Checkout src/sys/kern/uipc_socket2.c *** *** runtime error: *** Attempt to dereference NIL *** file "/vm/ports/usr/ports/lang/ezm3/work/ezm3-1.2/libs/libm3/src/rw/Common/RdImpl.m3", line 39 *** use option @M3stackdump to get a stack trace ----------- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 --0-1759118603-1151201545=:1114 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg.boot Content-Transfer-Encoding: BASE64 Content-ID: <20060624231225.Q1114@ganymede.hub.org> Content-Description: Content-Disposition: attachment; filename=dmesg.boot Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDYuMS1SQzEgIzA6IE1vbiBBcHIgMTAgMTc6MDM6 MjIgVVRDIDIwMDYNCiAgICByb290QG9wdXMuY3NlLmJ1ZmZhbG8uZWR1Oi91 c3Ivb2JqL3Vzci9zcmMvc3lzL1NNUA0KYWNwaV9hbGxvY193YWtldXBfaGFu ZGxlcjogY2FuJ3QgYWxsb2Mgd2FrZSBtZW1vcnkNClRpbWVjb3VudGVyICJp ODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQpDUFU6IElu dGVsKFIpIFBlbnRpdW0oUikgSUlJIENQVSAtIFMgICAgICAgICAxMjY2TUh6 ICgxMjYzLjQ1LU1IeiA2ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2Vu dWluZUludGVsIiAgSWQgPSAweDZiNCAgU3RlcHBpbmcgPSA0DQogIEZlYXR1 cmVzPTB4MzgzZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgs RlhTUixTU0U+DQpyZWFsIG1lbW9yeSAgPSA0MjI3NzkyODk2ICg0MDMxIE1C KQ0KYXZhaWwgbWVtb3J5ID0gNDE0MDA5MzQ0MCAoMzk0OCBNQikNCkFDUEkg QVBJQyBUYWJsZTogPElOVEVMICBTQ0IyMCAgID4NCkZyZWVCU0QvU01QOiBN dWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcw0KIGNwdTAg KEJTUCk6IEFQSUMgSUQ6ICAzDQogY3B1MSAoQVApOiBBUElDIElEOiAgMA0K ICAgIEFDUEktMDY5ODogKioqIFdhcm5pbmc6IFR5cGUgb3ZlcnJpZGUgLSBb REVCX10gaGFkIGludmFsaWQgdHlwZSAoSW50ZWdlcikgZm9yIFNjb3BlIG9w ZXJhdG9yLCBjaGFuZ2VkIHRvIChTY29wZSkNCiAgICBBQ1BJLTA2OTg6ICoq KiBXYXJuaW5nOiBUeXBlIG92ZXJyaWRlIC0gW01MSUJdIGhhZCBpbnZhbGlk IHR5cGUgKEludGVnZXIpIGZvciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0 byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBv dmVycmlkZSAtIFtEQVRBXSBoYWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZv ciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQ SS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtTSU9fXSBo YWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwg Y2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAqKiogV2Fybmlu ZzogVHlwZSBvdmVycmlkZSAtIFtTQl9fXSBoYWQgaW52YWxpZCB0eXBlIChT dHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUp DQogICAgQUNQSS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBvdmVycmlkZSAt IFtQTV9fXSBoYWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBv cGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAq KiogV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtJQ05UXSBoYWQgaW52YWxp ZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0 byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBv dmVycmlkZSAtIFtBQ1BJXSBoYWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZv ciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQ SS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtMRURQXSBo YWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwg Y2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAqKiogV2Fybmlu ZzogVHlwZSBvdmVycmlkZSAtIFtXVUVTXSBoYWQgaW52YWxpZCB0eXBlIChT dHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUp DQogICAgQUNQSS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBvdmVycmlkZSAt IFtXVVNFXSBoYWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBv cGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAq KiogV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtDU0I1XSBoYWQgaW52YWxp ZCB0eXBlIChTdHJpbmcpIGZvciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0 byAoU2NvcGUpDQogICAgQUNQSS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBv dmVycmlkZSAtIFtQTV9fXSBoYWQgaW52YWxpZCB0eXBlIChTdHJpbmcpIGZv ciBTY29wZSBvcGVyYXRvciwgY2hhbmdlZCB0byAoU2NvcGUpDQogICAgQUNQ SS0wNjk4OiAqKiogV2FybmluZzogVHlwZSBvdmVycmlkZSAtIFtCSU9TXSBo YWQgaW52YWxpZCB0eXBlIChJbnRlZ2VyKSBmb3IgU2NvcGUgb3BlcmF0b3Is IGNoYW5nZWQgdG8gKFNjb3BlKQ0KICAgIEFDUEktMDY5ODogKioqIFdhcm5p bmc6IFR5cGUgb3ZlcnJpZGUgLSBbQ01PU10gaGFkIGludmFsaWQgdHlwZSAo SW50ZWdlcikgZm9yIFNjb3BlIG9wZXJhdG9yLCBjaGFuZ2VkIHRvIChTY29w ZSkNCk1BRFQ6IEZvcmNpbmcgYWN0aXZlLWxvdyBwb2xhcml0eSBhbmQgbGV2 ZWwgdHJpZ2dlciBmb3IgU0NJDQppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJx cyAwLTE1IG9uIG1vdGhlcmJvYXJkDQppb2FwaWMxIDxWZXJzaW9uIDEuMT4g aXJxcyAxNi0zMSBvbiBtb3RoZXJib2FyZA0KbGFwaWMzOiBGb3JjaW5nIExJ TlQxIHRvIGVkZ2UgdHJpZ2dlcg0Ka2JkMSBhdCBrYmRtdXgwDQpucHgwOiBb RkFTVF0NCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQN Cm5weDA6IElOVCAxNiBpbnRlcmZhY2UNCmFjcGkwOiA8SU5URUwgU0NCMjA+ IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkN ClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6 IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1lcjA6IDwzMi1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHg1MDgtMHg1MGIgb24gYWNwaTANCmNwdTA6 IDxBQ1BJIENQVT4gb24gYWNwaTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNw aTANCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIw DQpmeHAwOiA8SW50ZWwgODI1NTAgUHJvLzEwMCBFdGhlcm5ldD4gcG9ydCAw eDE0MDAtMHgxNDNmIG1lbSAweGZlYWUwMDAwLTB4ZmVhZTBmZmYsMHhmZWFh MDAwMC0weGZlYWJmZmZmIGlycSAyMSBhdCBkZXZpY2UgMy4wIG9uIHBjaTAN Cm1paWJ1czA6IDxNSUkgYnVzPiBvbiBmeHAwDQppbnBoeTA6IDxpODI1NTUg MTAvMTAwIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMA0KaW5waHkwOiAg MTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZE WCwgYXV0bw0KZnhwMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDM6NDc6MzA6 YTc6MWINCmZ4cDE6IDxJbnRlbCA4MjU1MCBQcm8vMTAwIEV0aGVybmV0PiBw b3J0IDB4MTQ0MC0weDE0N2YgbWVtIDB4ZmVhODAwMDAtMHhmZWE4MGZmZiww eGZlYTYwMDAwLTB4ZmVhN2ZmZmYgaXJxIDIwIGF0IGRldmljZSA0LjAgb24g cGNpMA0KbWlpYnVzMTogPE1JSSBidXM+IG9uIGZ4cDENCmlucGh5MTogPGk4 MjU1NSAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMxDQppbnBo eTE6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNl VFgtRkRYLCBhdXRvDQpmeHAxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowMzo0 NzozMDphNzoxYw0KcGNpMDogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDEy LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmlzYWIwOiA8UENJLUlTQSBicmlk Z2U+IGF0IGRldmljZSAxNS4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBv biBpc2FiMA0KYXRhcGNpMDogPFNlcnZlcldvcmtzIENTQjUgVURNQTEwMCBj b250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3 LDB4Mzc2LDB4M2EwLTB4M2FmLDB4NDEwLTB4NDEzIGF0IGRldmljZSAxNS4x IG9uIHBjaTANCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQph dGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMA0Kb2hjaTA6IDxPSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmVhNDAwMDAtMHhm ZWE0MGZmZiBpcnEgMTAgYXQgZGV2aWNlIDE1LjIgb24gcGNpMA0Kb2hjaTA6 IFtHSUFOVC1MT0NLRURdDQp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdh Y3kgc3VwcG9ydA0KdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0 dGluZw0KdXNiMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biBvaGNpMA0KdXNiMDogVVNCIHJldmlzaW9uIDEuMA0KdWh1YjA6ICgweDEx NjYpIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxDQp1aHViMDogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQNCnBjaWIxOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFj cGkwDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQ0KaWlyMDogPElu dGVsIEludGVncmF0ZWQgUkFJRCBDb250cm9sbGVyPiBtZW0gMHhmYzhmMDAw MC0weGZjOGYzZmZmIGlycSAzMCBhdCBkZXZpY2UgOS4wIG9uIHBjaTENCmlp cjA6IFtHSUFOVC1MT0NLRURdDQpwY2liMjogPEFDUEkgSG9zdC1QQ0kgYnJp ZGdlPiBvbiBhY3BpMA0KcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIN CmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4gcG9ydCAw eDNmMi0weDNmMywweDNmNC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBh Y3BpMA0KZmRjMDogW0ZBU1RdDQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5v dCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMA0Kc2lvMDogcG9ydCBtYXkg bm90IGJlIGVuYWJsZWQNCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJsZSBDT00g cG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFj cGkwDQpzaW8wOiB0eXBlIDE2NTUwQQ0Kc2lvMTogY29uZmlndXJlZCBpcnEg MyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzE6IHBvcnQg bWF5IG5vdCBiZSBlbmFibGVkDQpzaW8xOiA8MTY1NTBBLWNvbXBhdGlibGUg Q09NIHBvcnQ+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTANCnNp bzE6IHR5cGUgMTY1NTBBDQpwbXRpbWVyMCBvbiBpc2EwDQpvcm0wOiA8SVNB IE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjZDgw MC0weGNlZmZmLDB4Y2YwMDAtMHhkMDdmZiwweGU0MDAwLTB4ZTdmZmYgb24g aXNhMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g YXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMA0KYXRrYmQwOiA8QVQgS2V5Ym9h cmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRrYmQwDQphdGtiZDA6 IFtHSUFOVC1MT0NLRURdDQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3Vu ZC4NCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBp c2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgz MDA+DQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4 M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQp1a2JkMDogREVM TCBERUxMIFVTQiBLZXlib2FyZCwgcmV2IDEuMTAvMS4wNSwgYWRkciAyLCBp Y2xhc3MgMy8xDQprYmQyIGF0IHVrYmQwDQpUaW1lY291bnRlcnMgdGljayBl dmVyeSAxLjAwMCBtc2VjDQphY2QwOiBDRFJPTSA8U0FNU1VORyBDRC1ST00g U04tMTI0L1FNMTU+IGF0IGF0YTAtbWFzdGVyIFBJTzQNCldhaXRpbmcgNSBz ZWNvbmRzIGZvciBTQ1NJIGRldmljZXMgdG8gc2V0dGxlDQpzZXMwIGF0IGlp cjAgYnVzIDEgdGFyZ2V0IDYgbHVuIDANCnNlczA6IDxFU0ctU0hWIFNDQSBI U0JQIE0xNiAwLjA1PiBGaXhlZCBQcm9jZXNzb3IgU0NTSS0yIGRldmljZSAN CnNlczA6IFNBRi1URSBDb21wbGlhbnQgRGV2aWNlDQpkYTAgYXQgaWlyMCBi dXMgMiB0YXJnZXQgMCBsdW4gMA0KZGEwOiA8SW50ZWwgSG9zdCBEcml2ZSAg ICMwMCA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRh MDogVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQNCmRhMDogMTM5ODc4TUIgKDI4 NjQ3MTA4MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE3ODMyQykN CmxhcGljMDogRm9yY2luZyBMSU5UMSB0byBlZGdlIHRyaWdnZXINClNNUDog QVAgQ1BVICMxIExhdW5jaGVkIQ0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJv bSB1ZnM6L2Rldi9kYTBzMWENCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJs eSBkaXNtb3VudGVkDQpXQVJOSU5HOiAvdG1wIHdhcyBub3QgcHJvcGVybHkg ZGlzbW91bnRlZA0KV0FSTklORzogL3VzciB3YXMgbm90IHByb3Blcmx5IGRp c21vdW50ZWQNCldBUk5JTkc6IC92YXIgd2FzIG5vdCBwcm9wZXJseSBkaXNt b3VudGVkDQpXQVJOSU5HOiAvdm0gd2FzIG5vdCBwcm9wZXJseSBkaXNtb3Vu dGVkDQo= --0-1759118603-1151201545=:1114-- From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 17:58:30 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A712E16A401; Sun, 25 Jun 2006 17:58:30 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E28A543D53; Sun, 25 Jun 2006 17:58:27 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuYsL-000I7L-Jr; Sun, 25 Jun 2006 18:58:25 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FuYsL-000HT3-H2; Sun, 25 Jun 2006 18:58:25 +0100 To: freebsd-stable@freeBSD.org, scrappy@hub.org In-Reply-To: <20060624212742.K1114@ganymede.hub.org> Message-Id: From: Pete French Date: Sun, 25 Jun 2006 18:58:25 +0100 Cc: freebsd-acpi@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 17:58:30 -0000 > 'k, I'm starting to get the impression that FreeBSD 6.x is evil ... at > least as far as Dual-PIII servers are concerned ... on a machine that, I can't comment on your other problems - but I have a dual PIII server and say a 30% performance increase when moving to 6.x over 5.x ... and it's been rock solid. I only run releases on that box though, but it does perform really nicely on PIII duals when you can get it stable. Seems a shame that you are having so many problems. -pete. From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 25 23:17:46 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C272216A401 for ; Sun, 25 Jun 2006 23:17:46 +0000 (UTC) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-ext.prodigy.net [207.115.63.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61D324408B for ; Sun, 25 Jun 2006 23:17:46 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.62.134] Received: from [10.0.5.51] (ppp-71-139-62-134.dsl.snfc21.pacbell.net [71.139.62.134]) by pimout6-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k5PNHh5v249848; Sun, 25 Jun 2006 19:17:44 -0400 Message-ID: <449EB6B4.1010601@root.org> Date: Sun, 25 Jun 2006 09:15:48 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: robertsg@westnet.com.au References: <200606232251.15593.robertsg@westnet.com.au> In-Reply-To: <200606232251.15593.robertsg@westnet.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi: bad write to port X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 23:17:46 -0000 Geoff Roberts wrote: > I'm not sure if this is the correct list, please let me know if it > belongs on another list. > > Since upgrading from 6.0 to the latest RELENG_6 branch the following > message appears every 10 seconds (exactly): > > Jun 22 15:00:06 emmapc kernel: acpi: bad write to port 0x070 (8), val > 0x59 > Jun 22 15:00:06 emmapc kernel: acpi: bad read from port 0x071 (8) > > I am using a Gigabyte GA60MM7E Rev 2.0 motherboard. It also has a PCI > SATA controller using a Si 3112 chip, a RealTek network card and a > Netgear WG311 wireless card. > > I've included the output of dmesg and pciconf -lv > > Any idea as to what might be causing this? Please let me know if there > is some more information required. The IO access has always been going on, we just started catching it recently. Those are the CMOS/RTC ports and it's not appropriate for the BIOS to access them. This is from OsdHardware.c log: revision 1.18 date: 2006/03/29 06:41:56; author: njl; state: Exp; lines: +76 -0 Add a blacklist for bad IO ports that AML should never touch. It seems some systems were designed so that AML writes to various resources shared with OS drivers, including the RTC, PIC, PCI, etc. These writes could collide with writes by the OS and should never be performed. For now, we print a message if such an access occurs, but do not block it. To block the access, the tunable "debug.acpi.block_bad_io" can be set to 1. In the future, we will flip the switch and this will become the default. Information about this problem was found in Microsoft KB 283649. They block IO accesses if the BIOS indicates via _OSI that it is Windows 2001 or higher. They always block accesses to the PIC, cascaded PIC, and ELCRs, no matter how old the BIOS. To test if disabling these writes hurts your system, try booting with debug.acpi.block_bad_io=1 set at the loader prompt. If there's a problem, let me know what happened. This helps us gather info for when we flip the switch to disabling such writes by default. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 07:52:53 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E0B16A404 for ; Mon, 26 Jun 2006 07:52:53 +0000 (UTC) (envelope-from doug@safeport.com) Received: from pemaquid.safeport.com (pemaquid.safeport.com [209.31.154.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFA54440D for ; Mon, 26 Jun 2006 07:34:56 +0000 (GMT) (envelope-from doug@safeport.com) Received: from localhost (localhost [127.0.0.1]) by pemaquid.safeport.com (8.13.4/8.12.11) with ESMTP id k5Q7YtJO068446 for ; Mon, 26 Jun 2006 03:34:56 -0400 (EDT) (envelope-from doug@safeport.com) Date: Mon, 26 Jun 2006 03:34:55 -0400 (EDT) From: doug@safeport.com To: freebsd-acpi@freebsd.org Message-ID: <20060626025813.M64069@pemaquid.safeport.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: acpi on thinkpad T42p X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 07:52:53 -0000 I am trying to get suspend/resuume working. I think what I have is a problem in the Xorg ATI driver, but I am not sure and would greatly appreciate some guidence. I am running 6.1 and Xorg 6.9.0. The S1 and S3 states worked with the only change being commenting out the DRI module in xorg.conf. My video shows as: none2@pci1:0:0: class=0x030000 card=0x054f1014 chip=0x4e541002 rev=0x80 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon Mobility M10 NT (RV350-WS)' class = display subclass = VGA Upon a resume from an S3 state the background is not restored, looking rather like a zebra (black and white lines). I can restore the background by forcing KDE to redraw it. Everything else except the built-in mouse is restored. I am using the ipw wireless driver, usually the network also comes back Loads and ssetting are: kldstat Id Refs Address Size Name 1 15 0xc0400000 69b3c4 kernel 2 1 0xc0a9c000 5f60 snd_ich.ko 3 2 0xc0aa2000 22b88 sound.ko 4 1 0xc0ac5000 97e0 if_ipw.ko 5 1 0xc0acf000 2d48 wlan_wep.ko 6 1 0xc0ad2000 4804 acpi_ibm.ko 7 2 0xc0ad7000 59960 acpi.ko 8 1 0xc5197000 16000 linux.ko hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 3 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.reset_video: 1 : dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 Am I correct in thinking the problem is in the ATI driver? _____ Douglas Denault http://www.safeport.com doug@safeport.com Voice: 301-469-8766 Fax: 301-469-0601 From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 09:11:11 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EB7C16A404; Mon, 26 Jun 2006 09:11:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA8344615; Mon, 26 Jun 2006 09:11:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5E6CD46CCB; Mon, 26 Jun 2006 05:11:06 -0400 (EDT) Date: Mon, 26 Jun 2006 10:11:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pete French In-Reply-To: Message-ID: <20060626100949.G24406@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scrappy@hub.org, freebsd-acpi@freebsd.org, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 09:11:11 -0000 On Sun, 25 Jun 2006, Pete French wrote: >> 'k, I'm starting to get the impression that FreeBSD 6.x is evil ... at >> least as far as Dual-PIII servers are concerned ... on a machine that, > > I can't comment on your other problems - but I have a dual PIII server and > say a 30% performance increase when moving to 6.x over 5.x ... and it's been > rock solid. I only run releases on that box though, but it does perform > really nicely on PIII duals when you can get it stable. Seems a shame that > you are having so many problems. I'm also running 6.x on several dual-PIII without problems. An issue local to Marc's setup is definitely indicated. Given the failure mode, I would be worried about a potential hardware issue, although subtle hardware and subtle system software problems are sometimes difficult to distinguish. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 11:02:50 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86AB616A4CB for ; Mon, 26 Jun 2006 11:02:50 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EFC943DA9 for ; Mon, 26 Jun 2006 11:02:41 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5QB2fU8042287 for ; Mon, 26 Jun 2006 11:02:41 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5QB2df8042283 for freebsd-acpi@freebsd.org; Mon, 26 Jun 2006 11:02:39 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 26 Jun 2006 11:02:39 GMT Message-Id: <200606261102.k5QB2df8042283@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 11:02:50 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/03/01] i386/93963 acpi [panic] [patch] ACPI Panic with some ACPI 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma o [2005/03/21] i386/79080 acpi acpi thermal changes freezes HP nx6110 o [2005/03/21] i386/79081 acpi ACPI suspend/resume not working on HP nx6 o [2005/04/28] i386/80426 acpi [APIC] [panic] 5.4-RC3 still panic when b o [2005/10/17] i386/87568 acpi [ACPI] [REGRESSION] 6.0-STABLE needs ACPI 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi [request] add thermal support to ACPI o [2004/11/11] kern/73823 acpi [feature request] acpi / power-on by time f [2004/11/17] kern/74030 acpi Unplugging AC causes battery % to stay lo f [2005/12/24] kern/90871 acpi ACPI problems with ASUS A8N-VM-CSM o [2006/05/30] kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 50 7 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 11:12:17 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17C2316A401; Mon, 26 Jun 2006 11:12:17 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E68F43D7B; Mon, 26 Jun 2006 11:12:14 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 32989290C99; Mon, 26 Jun 2006 08:12:10 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 01111-02; Mon, 26 Jun 2006 11:12:12 +0000 (UTC) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id AF278290C98; Mon, 26 Jun 2006 08:12:09 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 8A6503E7DF; Mon, 26 Jun 2006 08:12:17 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 837D73CF50; Mon, 26 Jun 2006 08:12:17 -0300 (ADT) Date: Mon, 26 Jun 2006 08:12:17 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20060626100949.G24406@fledge.watson.org> Message-ID: <20060626081029.L1114@ganymede.hub.org> References: <20060626100949.G24406@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, freebsd-stable@freeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 11:12:17 -0000 On Mon, 26 Jun 2006, Robert Watson wrote: > > On Sun, 25 Jun 2006, Pete French wrote: > >>> 'k, I'm starting to get the impression that FreeBSD 6.x is evil ... at >>> least as far as Dual-PIII servers are concerned ... on a machine that, >> >> I can't comment on your other problems - but I have a dual PIII server and >> say a 30% performance increase when moving to 6.x over 5.x ... and it's >> been rock solid. I only run releases on that box though, but it does >> perform really nicely on PIII duals when you can get it stable. Seems a >> shame that you are having so many problems. > > I'm also running 6.x on several dual-PIII without problems. An issue local > to Marc's setup is definitely indicated. Given the failure mode, I would be > worried about a potential hardware issue, although subtle hardware and subtle > system software problems are sometimes difficult to distinguish. Well, I've been trying to do it 'the hardway' ... went back to the original kernel, and am slowly upgrading forward ... I'm currently running a June 15th kernel with none of the problems that I was seeing before ... I'm just in the process of running my third 'make -j3 buildworld' on this kernel, and its clean ... going to go forward to June 22nd next, see if that too is clean *cross fingers* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 13:06:33 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 435E816A40B; Mon, 26 Jun 2006 13:06:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8477844914; Mon, 26 Jun 2006 13:06:32 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 133B846CCE; Mon, 26 Jun 2006 09:06:31 -0400 (EDT) Date: Mon, 26 Jun 2006 14:06:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20060626081029.L1114@ganymede.hub.org> Message-ID: <20060626140333.M38418@fledge.watson.org> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, freebsd-stable@freeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 13:06:33 -0000 On Mon, 26 Jun 2006, Marc G. Fournier wrote: >> I'm also running 6.x on several dual-PIII without problems. An issue local >> to Marc's setup is definitely indicated. Given the failure mode, I would >> be worried about a potential hardware issue, although subtle hardware and >> subtle system software problems are sometimes difficult to distinguish. > > Well, I've been trying to do it 'the hardway' ... went back to the original > kernel, and am slowly upgrading forward ... I'm currently running a June > 15th kernel with none of the problems that I was seeing before ... I'm just > in the process of running my third 'make -j3 buildworld' on this kernel, and > its clean ... going to go forward to June 22nd next, see if that too is > clean *cross fingers* I think this is a useful activity, especially if you've already run extensive memory testing on the box. If you haven't yet done that, I encourage you to take a break from buildworld's and make sure the memory tests pass. I spent several months on and off trying to track down a bug a few years ago, which turned out to be a one bit error in memory on the box. It would appear and disappear based on how the memory page was used -- for debugging kernels, it consistently got mapped to padding in the kernel's bss. For non-debugging kernels, it typically manifested in other usable kernel momory. Changes in kernel versions would move the bit around kernel memory and user memory, resulting in hard to debug failure modes. I wish I'd run the memory test earlier, but the lesson is clear! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 15:12:31 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDB8D16A47E; Mon, 26 Jun 2006 15:12:31 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB5E44A15; Mon, 26 Jun 2006 14:06:52 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id 97175290C1F; Mon, 26 Jun 2006 11:06:46 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 39814-03; Mon, 26 Jun 2006 14:06:50 +0000 (UTC) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id 2C678290C1E; Mon, 26 Jun 2006 11:06:46 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 73D175C279; Mon, 26 Jun 2006 11:06:57 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 7242D5C257; Mon, 26 Jun 2006 11:06:57 -0300 (ADT) Date: Mon, 26 Jun 2006 11:06:57 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20060626140333.M38418@fledge.watson.org> Message-ID: <20060626110636.I1114@ganymede.hub.org> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, freebsd-stable@freeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 15:12:32 -0000 On Mon, 26 Jun 2006, Robert Watson wrote: > > On Mon, 26 Jun 2006, Marc G. Fournier wrote: > >>> I'm also running 6.x on several dual-PIII without problems. An issue >>> local to Marc's setup is definitely indicated. Given the failure mode, I >>> would be worried about a potential hardware issue, although subtle >>> hardware and subtle system software problems are sometimes difficult to >>> distinguish. >> >> Well, I've been trying to do it 'the hardway' ... went back to the original >> kernel, and am slowly upgrading forward ... I'm currently running a June >> 15th kernel with none of the problems that I was seeing before ... I'm just >> in the process of running my third 'make -j3 buildworld' on this kernel, >> and its clean ... going to go forward to June 22nd next, see if that too is >> clean *cross fingers* > > I think this is a useful activity, especially if you've already run extensive > memory testing on the box. If you haven't yet done that, I encourage you to > take a break from buildworld's and make sure the memory tests pass. I spent > several months on and off trying to track down a bug a few years ago, which > turned out to be a one bit error in memory on the box. It would appear and > disappear based on how the memory page was used -- for debugging kernels, it > consistently got mapped to padding in the kernel's bss. For non-debugging > kernels, it typically manifested in other usable kernel momory. Changes in > kernel versions would move the bit around kernel memory and user memory, > resulting in hard to debug failure modes. I wish I'd run the memory test > earlier, but the lesson is clear! Is there something that I can run *from* FreeBSD, remotely, to do this? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 16:26:52 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3EF116A402; Mon, 26 Jun 2006 16:26:52 +0000 (UTC) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id C293B46585; Mon, 26 Jun 2006 16:26:43 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.62.134] Received: from [10.0.5.51] (ppp-71-139-62-134.dsl.snfc21.pacbell.net [71.139.62.134]) by pimout5-ext.prodigy.net (8.13.6 out.dk/8.13.6) with ESMTP id k5QGQelw195030; Mon, 26 Jun 2006 12:26:41 -0400 Message-ID: <449FA7DD.7000608@root.org> Date: Mon, 26 Jun 2006 02:24:45 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Robert Watson References: <20060626100949.G24406@fledge.watson.org> In-Reply-To: <20060626100949.G24406@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scrappy@hub.org, freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 16:26:53 -0000 Robert Watson wrote: > > On Sun, 25 Jun 2006, Pete French wrote: > >>> 'k, I'm starting to get the impression that FreeBSD 6.x is evil ... >>> at least as far as Dual-PIII servers are concerned ... on a machine >>> that, >> >> I can't comment on your other problems - but I have a dual PIII server >> and say a 30% performance increase when moving to 6.x over 5.x ... and >> it's been rock solid. I only run releases on that box though, but it >> does perform really nicely on PIII duals when you can get it stable. >> Seems a shame that you are having so many problems. > > I'm also running 6.x on several dual-PIII without problems. An issue > local to Marc's setup is definitely indicated. Given the failure mode, > I would be worried about a potential hardware issue, although subtle > hardware and subtle system software problems are sometimes difficult to > distinguish. If it passes the memtest x86 iso, let me know. Also, make sure there are no overrides of memory size in loader.conf. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 16:48:51 2006 Return-Path: X-Original-To: freebsd-acpi@freeBSD.org Delivered-To: freebsd-acpi@freeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E18B16A414; Mon, 26 Jun 2006 16:48:51 +0000 (UTC) (envelope-from jorn@wcborstel.com) Received: from mail.wcborstel.com (wcborstel.xs4all.nl [82.93.93.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C9E46489; Mon, 26 Jun 2006 16:17:20 +0000 (GMT) (envelope-from jorn@wcborstel.com) Received: from localhost (mail.wcborstel.com [10.0.0.2]) by mail.wcborstel.com (Postfix) with ESMTP id E67AE284CC1; Mon, 26 Jun 2006 18:17:18 +0200 (CEST) Received: from mail.wcborstel.com ([10.0.0.2]) by localhost (mail.wcborstel.com [10.0.0.2]) (amavisd-new, port 10024) with ESMTP id 80728-04; Mon, 26 Jun 2006 18:17:17 +0200 (CEST) Received: from [192.168.0.2] (unknown [192.168.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.wcborstel.com (Postfix) with ESMTP id 4A2B9284BA8; Mon, 26 Jun 2006 18:17:17 +0200 (CEST) Message-ID: <44A00881.8040302@wcborstel.com> Date: Mon, 26 Jun 2006 18:17:05 +0200 From: Jorn Argelo User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Marc G. Fournier" References: <20060624211229.X1114@ganymede.hub.org> <20060624212108.C1114@ganymede.hub.org> <449DE5AE.9000708@root.org> <20060624230418.P1114@ganymede.hub.org> In-Reply-To: <20060624230418.P1114@ganymede.hub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at wcborstel.com Cc: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 16:48:51 -0000 [sni[ > > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > ------------------------------------------------------------------------ > > Copyright (c) 1992-2006 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.1-RC1 #0: Mon Apr 10 17:03:22 UTC 2006 > root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP > acpi_alloc_wakeup_handler: can't alloc wake memory > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) III CPU - S 1266MHz (1263.45-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 > Features=0x383fbff > real memory = 4227792896 (4031 MB) > avail memory = 4140093440 (3948 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 3 > cpu1 (AP): APIC ID: 0 > ACPI-0698: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [WUES] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [WUSE] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [CSB5] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to (Scope) > ACPI-0698: *** Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to (Scope) > [snip] This looks pretty bad to me. I never seen anything like this before, and I've seen many x86 machines booting FreeBSD. Anybody knows what this means? Jorn From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 17:55:54 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CA6116A620 for ; Mon, 26 Jun 2006 17:55:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 482E6463F5 for ; Mon, 26 Jun 2006 17:32:12 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1079248uge for ; Mon, 26 Jun 2006 10:32:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lOrmVaAH9rVogfYBusLXWMGD6FobEKRM9vJNmoqDa+bEgXk6NP2EFB/4mABQks65umVzMoUMtf8UwKx1/B1t0u/b2JlzpBcqjM4iwqgl08rIhMP/qzuGPb83t4nESwpA7fXBixwhz3m6sDoGkJrVliF2ARU/Hb9H96b8EvV6fTQ= Received: by 10.78.151.3 with SMTP id y3mr2228291hud; Mon, 26 Jun 2006 10:32:11 -0700 (PDT) Received: by 10.78.23.18 with HTTP; Mon, 26 Jun 2006 10:32:11 -0700 (PDT) Message-ID: <2a41acea0606261032q15465d28x48d5174340bc7478@mail.gmail.com> Date: Mon, 26 Jun 2006 10:32:11 -0700 From: "Jack Vogel" To: "Jorn Argelo" In-Reply-To: <44A00881.8040302@wcborstel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060624211229.X1114@ganymede.hub.org> <20060624212108.C1114@ganymede.hub.org> <449DE5AE.9000708@root.org> <20060624230418.P1114@ganymede.hub.org> <44A00881.8040302@wcborstel.com> Cc: "Marc G. Fournier" , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 17:55:54 -0000 On 6/26/06, Jorn Argelo wrote: > [sni[ > > > > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ------------------------------------------------------------------------ > > > > Copyright (c) 1992-2006 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.1-RC1 #0: Mon Apr 10 17:03:22 UTC 2006 > > root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP > > acpi_alloc_wakeup_handler: can't alloc wake memory > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Pentium(R) III CPU - S 1266MHz (1263.45-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 > > Features=0x383fbff > > real memory = 4227792896 (4031 MB) > > avail memory = 4140093440 (3948 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > cpu0 (BSP): APIC ID: 3 > > cpu1 (AP): APIC ID: 0 > > ACPI-0698: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [WUES] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [WUSE] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [CSB5] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to (Scope) > > ACPI-0698: *** Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to (Scope) > > > [snip] > > This looks pretty bad to me. I never seen anything like this before, and > I've seen many x86 machines booting FreeBSD. Anybody knows what this means? A P3 box is fairly old, I could believe that ACPI might have problems with it. Hmmm, have you checked with the system or motherboard maker to get the latest and greatest BIOS? That might help. So, if you boot with ACPI disabled what happens? Cheers, Jack From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 26 21:01:18 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 257B716A404; Mon, 26 Jun 2006 21:01:18 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65D4A449E6; Mon, 26 Jun 2006 21:01:16 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5QL18dO006196; Tue, 27 Jun 2006 00:01:08 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 27 Jun 2006 00:01:08 +0300 (EEST) From: Dmitry Pryanishnikov To: Robert Watson In-Reply-To: <20060626140333.M38418@fledge.watson.org> Message-ID: <20060626235355.Q95667@atlantis.atlantis.dp.ua> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Marc G. Fournier" , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 21:01:18 -0000 Hello! On Mon, 26 Jun 2006, Robert Watson wrote: > I think this is a useful activity, especially if you've already run extensive > memory testing on the box. If you haven't yet done that, I encourage you to > take a break from buildworld's and make sure the memory tests pass. I spent > several months on and off trying to track down a bug a few years ago, which > turned out to be a one bit error in memory on the box. It would appear and This is precisely the task which hardware ECC solves: to correct any single- bit memory error and to detect 2-bit and most of several-bit errors. I prefer ECC-capable hardware even for home PC; for server it's a must IMHO. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 27 08:43:51 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F12E716A40A; Tue, 27 Jun 2006 08:43:51 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B2D343D5A; Tue, 27 Jun 2006 08:43:51 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5R8hiTr030722 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Jun 2006 18:43:45 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5R8hhj6001177; Tue, 27 Jun 2006 18:43:43 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5R8hhBx001176; Tue, 27 Jun 2006 18:43:43 +1000 (EST) (envelope-from peter) Date: Tue, 27 Jun 2006 18:43:43 +1000 From: Peter Jeremy To: Dmitry Pryanishnikov Message-ID: <20060627084343.GD714@turion.vk2pj.dyndns.org> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> <20060626235355.Q95667@atlantis.atlantis.dp.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline In-Reply-To: <20060626235355.Q95667@atlantis.atlantis.dp.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 08:43:52 -0000 --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Jun-27 00:01:08 +0300, Dmitry Pryanishnikov wrote: >On Mon, 26 Jun 2006, Robert Watson wrote: >>I think this is a useful activity, especially if you've already run=20 >>extensive memory testing on the box. If you haven't yet done that, I=20 >>encourage you to take a break from buildworld's and make sure the memory= =20 >>tests pass. I spent several months on and off trying to track down a bug = a=20 >>few years ago, which turned out to be a one bit error in memory on the=20 >>box. It would appear and > > This is precisely the task which hardware ECC solves: to correct any=20 > single-bit memory error and to detect 2-bit and most of several-bit error= s. Parity will detect any odd number of bits in error. ECC can typically correct correct one bit and detect 2 or any odd number of errors. Note that ECC only checks the path between the RAM and DRAM controller (eg northbridge). You can also get errors between the northbridge and the CPU (including the cache). Some caches (eg Alpha) have parity to help here. Mainframes typically have ECC or parity on _all_ datapaths (including through the ALU) to catch those errors. --=20 Peter Jeremy --u65IjBhB3TIa72Vp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEoO++/opHv/APuIcRAjh4AKCpQxE5JR5nY4oFl1nFMojyCFrQhACfXFKM kJfxbJmKb6+KADP0vQM6OzM= =Rj5H -----END PGP SIGNATURE----- --u65IjBhB3TIa72Vp-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 27 13:16:19 2006 Return-Path: X-Original-To: freebsd-acpi@freeBSD.org Delivered-To: freebsd-acpi@freeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52C5116A401; Tue, 27 Jun 2006 13:16:19 +0000 (UTC) (envelope-from malikdj@hotmail.com) Received: from hotmail.com (bay114-f37.bay114.hotmail.com [65.54.169.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CAA43D6D; Tue, 27 Jun 2006 13:16:14 +0000 (GMT) (envelope-from malikdj@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 06:16:14 -0700 Message-ID: Received: from 65.54.169.200 by by114fd.bay114.hotmail.msn.com with HTTP; Tue, 27 Jun 2006 13:16:11 GMT X-Originating-IP: [192.76.82.89] X-Originating-Email: [malikdj@hotmail.com] X-Sender: malikdj@hotmail.com In-Reply-To: <44A00881.8040302@wcborstel.com> From: "Eprha Carvajal" To: jorn@wcborstel.com, scrappy@hub.org Date: Tue, 27 Jun 2006 13:16:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Jun 2006 13:16:14.0455 (UTC) FILETIME=[DDD25070:01C699EB] Cc: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 13:16:19 -0000 I see no ACPI capability in the processor features FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE also seems to be failing right after loading the acpi module ===>acpi_alloc_wakeup_handler: can't alloc wake memory perphaps your bios is broker. >From: Jorn Argelo >To: "Marc G. Fournier" >CC: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org >Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... >Date: Mon, 26 Jun 2006 18:17:05 +0200 > >[sni[ >> >>Yahoo . yscrappy Skype: hub.org ICQ . 7615664 >>------------------------------------------------------------------------ >> >>Copyright (c) 1992-2006 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.1-RC1 #0: Mon Apr 10 17:03:22 UTC 2006 >> root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP >>acpi_alloc_wakeup_handler: can't alloc wake memory >>Timecounter "i8254" frequency 1193182 Hz quality 0 >>CPU: Intel(R) Pentium(R) III CPU - S 1266MHz (1263.45-MHz >>686-class CPU) >> Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 >> >>Features=0x383fbff >>real memory = 4227792896 (4031 MB) >>avail memory = 4140093440 (3948 MB) >>ACPI APIC Table: >>FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 3 >> cpu1 (AP): APIC ID: 0 >> ACPI-0698: *** Warning: Type override - [DEB_] had invalid type >>(Integer) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [MLIB] had invalid type >>(Integer) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [DATA] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [SIO_] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [SB__] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [PM__] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [ICNT] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [ACPI] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [LEDP] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [WUES] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [WUSE] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [CSB5] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [PM__] had invalid type >>(String) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [BIOS] had invalid type >>(Integer) for Scope operator, changed to (Scope) >> ACPI-0698: *** Warning: Type override - [CMOS] had invalid type >>(Integer) for Scope operator, changed to (Scope) >> >[snip] > >This looks pretty bad to me. I never seen anything like this before, and >I've seen many x86 machines booting FreeBSD. Anybody knows what this means? > >Jorn >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 27 13:41:43 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 936EF16A400; Tue, 27 Jun 2006 13:41:43 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E7F43D6A; Tue, 27 Jun 2006 13:41:37 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id C417E290C25; Tue, 27 Jun 2006 10:41:30 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 76375-09; Tue, 27 Jun 2006 13:41:36 +0000 (UTC) Received: from ganymede.hub.org (blk-7-151-244.eastlink.ca [71.7.151.244]) by hub.org (Postfix) with ESMTP id 7130A290C1E; Tue, 27 Jun 2006 10:41:29 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id BD5434919F; Tue, 27 Jun 2006 10:41:39 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id BAF04454EF; Tue, 27 Jun 2006 10:41:39 -0300 (ADT) Date: Tue, 27 Jun 2006 10:41:39 -0300 (ADT) From: "Marc G. Fournier" To: Eprha Carvajal In-Reply-To: Message-ID: <20060627104044.O1114@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freeBSD.org, jorn@wcborstel.com, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 13:41:43 -0000 Based on postings I've found in Google, the Warnings below are just that, and shouldn't affect the operation of the server ... in fact, my other Dual-PIII is running fine, so I'm currently running under the assumption that one of the CPUs has just finally given up the ghost, and that it isn't an OS issue ... On Tue, 27 Jun 2006, Eprha Carvajal wrote: > > I see no ACPI capability in the processor features > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE > > also seems to be failing right after loading the acpi module > ===>acpi_alloc_wakeup_handler: can't alloc wake memory > > perphaps your bios is broker. > >> From: Jorn Argelo >> To: "Marc G. Fournier" >> CC: freebsd-acpi@freeBSD.org, freebsd-stable@freeBSD.org >> Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... >> Date: Mon, 26 Jun 2006 18:17:05 +0200 >> >> [sni[ >>> >>> Yahoo . yscrappy Skype: hub.org ICQ . 7615664 >>> ------------------------------------------------------------------------ >>> >>> Copyright (c) 1992-2006 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.1-RC1 #0: Mon Apr 10 17:03:22 UTC 2006 >>> root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP >>> acpi_alloc_wakeup_handler: can't alloc wake memory >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Pentium(R) III CPU - S 1266MHz (1263.45-MHz >>> 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 >>> Features=0x383fbff >>> real memory = 4227792896 (4031 MB) >>> avail memory = 4140093440 (3948 MB) >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> cpu0 (BSP): APIC ID: 3 >>> cpu1 (AP): APIC ID: 0 >>> ACPI-0698: *** Warning: Type override - [DEB_] had invalid type >>> (Integer) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [MLIB] had invalid type >>> (Integer) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [DATA] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [SIO_] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [SB__] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [PM__] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [ICNT] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [ACPI] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [LEDP] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [WUES] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [WUSE] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [CSB5] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [PM__] had invalid type >>> (String) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [BIOS] had invalid type >>> (Integer) for Scope operator, changed to (Scope) >>> ACPI-0698: *** Warning: Type override - [CMOS] had invalid type >>> (Integer) for Scope operator, changed to (Scope) >>> >> [snip] >> >> This looks pretty bad to me. I never seen anything like this before, and >> I've seen many x86 machines booting FreeBSD. Anybody knows what this means? >> >> Jorn >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 28 04:09:28 2006 Return-Path: X-Original-To: freebsd-acpi@freeBSD.org Delivered-To: freebsd-acpi@freeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 213D916A40F; Wed, 28 Jun 2006 04:09:28 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E4B144B00; Wed, 28 Jun 2006 02:15:18 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 039C7382; Tue, 27 Jun 2006 21:15:18 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 23D9F61C2B; Tue, 27 Jun 2006 21:15:17 -0500 (CDT) Date: Tue, 27 Jun 2006 21:15:17 -0500 From: "Matthew D. Fuller" To: Eprha Carvajal Message-ID: <20060628021516.GI32650@over-yonder.net> References: <44A00881.8040302@wcborstel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: scrappy@hub.org, freebsd-acpi@freeBSD.org, jorn@wcborstel.com, freebsd-stable@freeBSD.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 04:09:28 -0000 On Tue, Jun 27, 2006 at 01:16:11PM +0000 I heard the voice of Eprha Carvajal, and lo! it spake thus: > > I see no ACPI capability in the processor features ACPI is not a CPU feature. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 28 14:59:36 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AB4516A49E; Wed, 28 Jun 2006 14:59:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83325444B3; Wed, 28 Jun 2006 14:35:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 33FE446C17; Wed, 28 Jun 2006 10:34:59 -0400 (EDT) Date: Wed, 28 Jun 2006 15:34:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <20060626110636.I1114@ganymede.hub.org> Message-ID: <20060628153222.I65342@fledge.watson.org> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> <20060626110636.I1114@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, freebsd-stable@freeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 14:59:36 -0000 On Mon, 26 Jun 2006, Marc G. Fournier wrote: >> I think this is a useful activity, especially if you've already run >> extensive memory testing on the box. If you haven't yet done that, I >> encourage you to take a break from buildworld's and make sure the memory >> tests pass. I spent several months on and off trying to track down a bug a >> few years ago, which turned out to be a one bit error in memory on the box. >> It would appear and disappear based on how the memory page was used -- for >> debugging kernels, it consistently got mapped to padding in the kernel's >> bss. For non-debugging kernels, it typically manifested in other usable >> kernel momory. Changes in kernel versions would move the bit around kernel >> memory and user memory, resulting in hard to debug failure modes. I wish >> I'd run the memory test earlier, but the lesson is clear! > > Is there something that I can run *from* FreeBSD, remotely, to do this? Not that I know of. In the past, the discussion has been held about adopting a memory tester into the boot loader, which is almost certainly the right place to put it (before VM kicks off and we load many megabytes of critical data structures, etc). Some hands to make this happen would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 28 15:41:24 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1756016A40F; Wed, 28 Jun 2006 15:41:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2490343D64; Wed, 28 Jun 2006 15:41:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5SFfFLK026519; Wed, 28 Jun 2006 11:41:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 28 Jun 2006 10:29:04 -0400 User-Agent: KMail/1.9.1 References: <44A00881.8040302@wcborstel.com> <20060628021516.GI32650@over-yonder.net> In-Reply-To: <20060628021516.GI32650@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606281029.05153.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Jun 2006 11:41:22 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1571/Wed Jun 28 08:16:22 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: scrappy@hub.org, jorn@wcborstel.com, freebsd-stable@freebsd.org, "Matthew D. Fuller" Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 15:41:24 -0000 On Tuesday 27 June 2006 22:15, Matthew D. Fuller wrote: > On Tue, Jun 27, 2006 at 01:16:11PM +0000 I heard the voice of > Eprha Carvajal, and lo! it spake thus: > > > > I see no ACPI capability in the processor features > > ACPI is not a CPU feature. There is an 'ACPI' feature bit, but I think it has to do with preserving the TSC rate while the CPU is throttled. It's not required for core ACPI operation. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 28 21:06:14 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53AEB16A5D0; Wed, 28 Jun 2006 21:06:14 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C37144C24; Wed, 28 Jun 2006 20:45:10 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k5SKj6al021286; Wed, 28 Jun 2006 16:45:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060628153222.I65342@fledge.watson.org> References: <20060626100949.G24406@fledge.watson.org> <20060626081029.L1114@ganymede.hub.org> <20060626140333.M38418@fledge.watson.org> <20060626110636.I1114@ganymede.hub.org> <20060628153222.I65342@fledge.watson.org> Date: Wed, 28 Jun 2006 16:45:05 -0400 To: Robert Watson , "Marc G. Fournier" From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org, Pete French Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 21:06:14 -0000 At 3:34 PM +0100 6/28/06, Robert Watson wrote: >On Mon, 26 Jun 2006, Marc G. Fournier wrote: > >>>I wish I'd run the memory test earlier, but the lesson >>>is clear! >> >>Is there something that I can run *from* FreeBSD, remotely, >>to do this? > >Not that I know of. In the past, the discussion has been >held about adopting a memory tester into the boot loader, >which is almost certainly the right place to put it (before >VM kicks off and we load many megabytes of critical data >structures, etc). Some hands to make this happen would >be most welcome. It doesn't even need to be *inside* the boot loader, does it? Could it be done as an alternate-kernel that could be loaded by the boot-loader? -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 28 21:47:25 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6230E16A412; Wed, 28 Jun 2006 21:47:25 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id BED3244D17; Wed, 28 Jun 2006 21:47:24 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id C7E8E261; Wed, 28 Jun 2006 16:47:23 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 0404861C2B; Wed, 28 Jun 2006 16:47:22 -0500 (CDT) Date: Wed, 28 Jun 2006 16:47:22 -0500 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20060628214722.GO32650@over-yonder.net> References: <44A00881.8040302@wcborstel.com> <20060628021516.GI32650@over-yonder.net> <200606281029.05153.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606281029.05153.jhb@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.3 Cc: freebsd-acpi@freebsd.org, jorn@wcborstel.com, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.x CVSUP today crashes with zero load ... X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 21:47:25 -0000 On Wed, Jun 28, 2006 at 10:29:04AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: > > There is an 'ACPI' feature bit, but I think it has to do with > preserving the TSC rate while the CPU is throttled. It's not > required for core ACPI operation. Ah, well, I stand corrected. I have a number of systems with ACPI, but none of them ever showed such a bit. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 30 01:55:12 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F18FB16A416 for ; Fri, 30 Jun 2006 01:55:11 +0000 (UTC) (envelope-from gofda-freebsd-acpi@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E911343D48 for ; Fri, 30 Jun 2006 01:55:10 +0000 (GMT) (envelope-from gofda-freebsd-acpi@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Fw8Do-00022g-1R for freebsd-acpi@freebsd.org; Fri, 30 Jun 2006 03:55:04 +0200 Received: from gw205.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Jun 2006 03:55:03 +0200 Received: from atkin901 by gw205.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Jun 2006 03:55:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-acpi@freebsd.org From: othermark Date: Thu, 29 Jun 2006 14:51:34 -0700 Lines: 812 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gw205.f5.com User-Agent: KNode/0.10.2 Sender: news Subject: acpi on msi-9218 (-current) swaps sio0 and sio1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 01:55:12 -0000 With acpi loaded on a msi-9218 motherboard, I'm seeing sio0 and sio1 get 'swapped.' Even though the kernel is compiled for console on 0x3f8, I've had to change the /etc/ttys to use ttyd1 so login is displayed when the system is booted. Empirically, this tells me that 0x3f8 is correct for sio0 (since the kernel and boot loader display fine using it as comconsole). Is there a way to force this to be consistant? This is -current from Jun 8. I will try a more recent kernel soon. The following is a verbose boot log. Note that the LCD driver tries to use cuad0 since the console is using ttyd1 (cuad0) after bootup. However, since the kernel output has ttyd0/sio0/cuad0 tied up, it fails to attach. It will attach later after bootup, but not work. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #1: Thu Jun 8 08:11:00 PDT 2006 root@pogo-1.f5test.net:/usr/obj/usr/src/sys/POGO WARNING: WITNESS option enabled, expect reduced performance. Using 32 colors for the VM-PQ tuning (1024, 8) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0cdb000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0cdb1a8. MP Configuration Table version 1.4 found at 0xc009fda1 Table 'FACP' at 0x3fe9cda9 Table 'ASF!' at 0x3fe9ce1d Table 'SPCR' at 0x3fe9cee4 Table 'MCFG' at 0x3fe9cf34 Table 'APIC' at 0x3fe9cf70 MADT: Found table at 0x3fe9cf70 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) INTR: Adding local APIC 0 as a target ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193219 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3192019656 Hz CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3192.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 byte line size L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line real memory = 1072234496 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001028000 - 0x000000003ec55fff, 1036181504 bytes (252974 pages) avail memory = 1035837440 (987 MB) INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f60f0 bios32: Entry = 0xfd450 (c00fd450) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd450+0x34c pnpbios: Found PnP BIOS data at 0xc00f6180 pnpbios: Entry = f0000:a9fa Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) rr232x: RocketRAID 232x controller driver v1.02 (Jun 8 2006 08:10:46) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fa20 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27788086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 10 11 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 10 11 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 10 11 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 10 11 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 10 11 14 15 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1010 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x81 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0x81 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0100, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e0, revid=0x01 bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e2, revid=0x01 bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00003020, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type 4, range 32, base 00003040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 00003060, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d8500000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 000030a0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 000030e8, size 3, enabled map[14]: type 4, range 32, base 000030dc, size 2, enabled map[18]: type 4, range 32, base 000030e0, size 3, enabled map[1c]: type 4, range 32, base 000030d8, size 2, enabled map[20]: type 4, range 32, base 000030b0, size 4, enabled map[24]: type 1, range 32, base d8500400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pci1: on pcib1 pci1: physical bus=1 pcib2: irq 17 at device 28.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0x0-0x0 pcib2: prefetched decode 0x0-0x0 pci2: on pcib2 pci2: physical bus=2 pcib3: irq 17 at device 28.4 on pci0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xd8000000-0xd80fffff pcib3: prefetched decode 0xfff00000-0xfffff pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8000000, size 17, enabled pcib3: (null) requested memory range 0xd8000000-0xd801ffff: good map[18]: type 4, range 32, base 00004000, size 5, enabled pcib3: (null) requested I/O range 0x4000-0x401f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 em0: port 0x4000-0x401f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0x4000 em0: bpf attached em0: Ethernet address: 00:13:d3:fe:05:8e ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 em0: [FAST] pcib4: irq 16 at device 28.5 on pci0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xd8100000-0xd81fffff pcib4: prefetched decode 0xfff00000-0xfffff pci4: on pcib4 pci4: physical bus=4 found-> vendor=0x8086, dev=0x108b, revid=0x00 bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d8100000, size 17, enabled pcib4: (null) requested memory range 0xd8100000-0xd811ffff: good map[18]: type 4, range 32, base 00005000, size 5, enabled pcib4: (null) requested I/O range 0x5000-0x501f: in range pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 em1: port 0x5000-0x501f mem 0xd8100000-0xd811ffff irq 17 at device 0.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8100000 em1: Reserved 0x20 bytes for rid 0x18 type 4 at 0x5000 em1: bpf attached em1: Ethernet address: 00:13:d3:fe:05:8f ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 em1: [FAST] uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8500000-0xd85003ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8500000 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: prefetched decode 0xd0000000-0xd7ffffff pcib5: Subtractively decoded bridge. pci10: on pcib5 pci10: physical bus=10 found-> vendor=0x1002, dev=0x5159, revid=0x00 bus=10, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base d0000000, size 27, enabled pcib5: (null) requested memory range 0xd0000000-0xd7ffffff: good map[14]: type 4, range 32, base 00006000, size 8, enabled pcib5: (null) requested I/O range 0x6000-0x60ff: in range map[18]: type 1, range 32, base d8200000, size 16, enabled pcib5: (null) requested memory range 0xd8200000-0xd820ffff: good pcib5: matched entry for 10.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 vgapci0: port 0x6000-0x60ff mem 0xd0000000-0xd7ffffff,0xd8200000-0xd820ffff irq 16 at device 0.0 on pci10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 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=51 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 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=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xd8500400-0xd85007ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 atapci1: [MPSAFE] atapci1: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd8500400 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30e8 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30dc ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30e0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30d8 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: irq maps: 0x4c21 0x4c29 0x4c21 0x4c21 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 3 (ISA IRQ 3) to vector 56 sio0: [FAST] sio1: irq maps: 0x4c21 0x4c31 0x4c21 0x4c21 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio1: [FAST] psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 psm0: failed to reset the aux device. ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff 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 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xdc000-0xdffff,0xe0000-0xe17ff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750618 hz Timecounter "TSC" frequency 3192019656 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached rr232x: no controller detected. em0: Link is up 1000 Mbps Full Duplex em1: Link is up 1000 Mbps Full Duplex ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 76319MB at ata3-master SATA150 ad6: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 INTR: Assigning IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 1 to local APIC 0 INTR: Assigning IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 3 to local APIC 1 INTR: Assigning IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 0 INTR: Assigning IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 1 INTR: Assigning IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 0 INTR: Assigning IRQ 15 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 1 INTR: Assigning IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 0 INTR: Assigning IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 17 to local APIC 1 INTR: Assigning IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 0 INTR: Assigning IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 1 INTR: Assigning IRQ 23 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 0 Trying to mount root from ufs:/dev/ad6s1a start_init: trying /sbin/init Loading configuration files. kernel dumps on /dev/ad6s1b Entropy harvesting: interrupts ethernet point_to_point kickstart . swapon: adding /dev/ad6s1b as swap device Starting file system checks: /dev/ad6s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1a: clean, 35769111 free (9167 frags, 4469993 blocks, 0.0% fragmentation) Setting hostname: pogo-2.f5test.net. em0: Link is Down em1: Link is Down lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 mtu 1500 options=8b inet6 fe80::213:d3ff:fefe:58e%em0 prefixlen 64 tentative scopeid 0x1 inet 172.16.17.2 netmask 0xfffff000 broadcast 172.16.31.255 ether 00:13:d3:fe:05:8e media: Ethernet autoselect status: no carrier em1: flags=8843 mtu 1500 options=8b inet6 fe80::213:d3ff:fefe:58f%em1 prefixlen 64 tentative scopeid 0x2 inet 172.16.64.2 netmask 0xfffff000 broadcast 172.16.79.255 ether 00:13:d3:fe:05:8f media: Ethernet autoselect status: no carrier Starting devd. hw.acpi.cpu.cx_lowest: C1 -> C1 add net 172.16.240.0: gateway 172.16.31.33 Additional routing options: . add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 -> 0 net.inet6.ip6.accept_rtadv: 0 -> 1 em0: Link is up 1000 Mbps Full Duplex em1: Link is up 1000 Mbps Full Duplex add net fe80::: gateway ::1 add net ff02::: gateway ::1 IPv4 mapped IPv6 address support=YES Mounting NFS file systems: . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files: . Starting syslogd. Checking for core dump on /dev/ad6s1b... savecore: no dumps found Initial i386 initialization: . Additional ABI support: . NFS access cache time=60 Starting lighttpd. Starting LCDd. Jun 29 14:36:29 pogo-2 LCDd: ms6931: open(/dev/cuad0) failed (Device busy) Jun 29 14:36:29 pogo-2 LCDd: Driver [ms6931] init failed, return code < 0 Jun 29 14:36:29 pogo-2 LCDd: Could not load driver ms6931 Jun 29 14:36:29 pogo-2 LCDd: There is no output driver Jun 29 14:36:29 pogo-2 LCDd: Critical error while initializing, abort. Starting lcdproc. Error connecting to LCD server localhost on port 13666. Check to see that the server is running and operating normally. Starting local daemons: . Updating motd . Starting ntpd. Configuring syscons: blanktime . Starting sshd. Starting cron. Local package initialization: . Additional TCP options: . Starting inetd. Starting background file system checks in 60 seconds. Thu Jun 29 14:36:30 PDT 2006 Jun 29 14:36:36 pogo-2 login: ROOT LOGIN (root) ON ttyd1 -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 30 16:26:50 2006 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BA4B16A59B for ; Fri, 30 Jun 2006 16:26:50 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FD4C4442A for ; Fri, 30 Jun 2006 16:06:46 +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 for ; Fri, 30 Jun 2006 09:06:43 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D8DC245043 for ; Fri, 30 Jun 2006 09:06:42 -0700 (PDT) To: acpi@freebsd.org Date: Fri, 30 Jun 2006 09:06:42 -0700 From: "Kevin Oberman" Message-Id: <20060630160642.D8DC245043@ptavv.es.net> Cc: Subject: New errors when booting current X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2006 16:26:50 -0000 I am seeing large numbers of "bad write" and "bad read" errors from acpi since my last update of the OS. I'm getting these from both desktops with minimal ACPI capability and my laptop. I don't see any problems, so I suspect they are cosmetic, but I am curious as to what changed to trigger them and whether they might be eliminated. Let me know if you want to see my ASL, but it seems to be happening on all of my current systems. Here is an excerpt from my dmesg on the desktop: acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x22 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x22 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x22 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x22 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x26 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x55 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x25 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x23 acpi: bad read from port 0x071 (8) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 acpi: bad read from port 0x071 (8) acpi: bad write to port 0x070 (8), val 0x77 acpi: bad write to port 0x071 (8), val 0 acpi: bad write to port 0x070 (8), val 0x77 -- 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