From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 22 11:06:48 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616A6106564A for ; Mon, 22 Sep 2008 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5191C8FC1C for ; Mon, 22 Sep 2008 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8MB6mTC015271 for ; Mon, 22 Sep 2008 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8MB6l4Q015267 for freebsd-acpi@FreeBSD.org; Mon, 22 Sep 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Sep 2008 11:06:47 GMT Message-Id: <200809221106.m8MB6l4Q015267@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org 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, 22 Sep 2008 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 41 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 22 15:29:12 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C68801065671; Mon, 22 Sep 2008 15:29:12 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9538FC15; Mon, 22 Sep 2008 15:29:12 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 0356B55CF0; Mon, 22 Sep 2008 16:09:57 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id c5C+83CVD64x; Mon, 22 Sep 2008 16:09:52 +0100 (BST) Received: by nemesis.charlie.mouhaha.de (Postfix, from userid 1001) id 98BF555CE0; Mon, 22 Sep 2008 16:09:52 +0100 (BST) Date: Mon, 22 Sep 2008 16:09:52 +0100 From: Oliver Peter To: John Baldwin Message-ID: <20080922150952.GA37948@nemesis.frida.mouhaha.de> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> <200809091424.16302.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809091424.16302.jhb@freebsd.org> X-Operating-System: FreeBSD 7.0-RELEASE-p3 amd64 User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] 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, 22 Sep 2008 15:29:12 -0000 On Tue, Sep 09, 2008 at 02:24:16PM -0400, John Baldwin wrote: > On Monday 08 September 2008 07:08:05 pm Oliver Peter wrote: > > ... > > ... of course I could do that - but could you please be so kind and > > explain how to do that? :-) > > Well, you could start by adding a printf to ata's interrupt handler, but that > would result in a flood on your screen. You could maybe use a KTR instead, > but only do it if the interrupt handler doesn't find any work to do (e.g. no > pending request) perhaps. I think the ATA interrrupt handler already reads a > status register of some sort, but I could be wrong. I feels like I need a rosetta stone for that... :) This is my "production" machine in the datacenter 2,000km away - I would love to debug that interrupt storm with KTR, but I'm not sure what I'm doing at all and nobody can ensure that my machine will come up again after that... Anyway I would like to learn more about the KTR stuff. I've never heard about that before, is that a good point to start out? http://www.watson.org/~robert/freebsd/netperf/ktr/ Furthermore I found out that this interrupt storm actally HAS a very bad impact in I/O performance of the harddisks... I'm at 9MB/s writing speed with dd. Normally I'm at about 60MB/s. Cheers. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 22 15:47:28 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 894271065675 for ; Mon, 22 Sep 2008 15:47:28 +0000 (UTC) (envelope-from numardbsd@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 030358FC12 for ; Mon, 22 Sep 2008 15:47:27 +0000 (UTC) (envelope-from numardbsd@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so741688tid.3 for ; Mon, 22 Sep 2008 08:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:face:mime-version :content-type:content-transfer-encoding; bh=J2sK3hASE4yqekECfKTFbtewOE96/8yC0MpTZ+rOIIM=; b=HHySJkosVQThJ5Wkk6fb5/OuXf8hLz21QOsIUOw7Lk72/8yI/+3wfE9YgcnkhUUDfk wiewUD3PxqGeOEVpI3ZCHKY+cDhEsjTeKC2MGf3qi5+IeeyMDPjdvVytet81snBLDS5H RrPMubRPabJ6OUatKnA9gaI11IwMxbVtyruJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :face:mime-version:content-type:content-transfer-encoding; b=soMi1RtOJZlVxcKG+0ZGpn6ZW+j66ZXQaQaLqnOI//5+y/TVcQqLv4y6+HQqHBrj/u rzt25yGHawLYB9mQVG21KV8s1KaWbBC8ZlhdGp9U/5sXk6kKoBVRyPse28f3x55asbEe 56tLnoM+vfvQXM9P0q1zch7Zk9j5YuPd1cKcA= Received: by 10.110.53.14 with SMTP id b14mr5253552tia.8.1222096487769; Mon, 22 Sep 2008 08:14:47 -0700 (PDT) Received: from ayiin ( [203.166.246.80]) by mx.google.com with ESMTPS id d4sm1229586tib.1.2008.09.22.08.14.45 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Sep 2008 08:14:46 -0700 (PDT) Date: Tue, 23 Sep 2008 01:14:41 +1000 From: Norberto Meijome To: freebsd-acpi@freebsd.org Message-ID: <20080923011441.17751f9a@ayiin> In-Reply-To: <1221680202.1720.10.camel@t43.juergendankoweit.net> References: <1221680202.1720.10.camel@t43.juergendankoweit.net> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Thinkap T43 suspend/resume only once 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, 22 Sep 2008 15:47:28 -0000 On Wed, 17 Sep 2008 21:36:42 +0200 Juergen Dankoweit wrote: > But there is one point that does not work correctly. > When I press the Fn+F4 buttons the first time after booting the system, > ACPI mode S3 is called correctly and the notebook goes into suspend > mode. After pressing Fn alone the notebook resumes perfekt. > > But when I press Fn+F4 the next time, nothing happens. Entering > "acpiconf -s 3" suspends the notebook and resuming is no problem Hi Juergen, does any other fn- key act in a different way (well, stops working) after the first restore? maybe not related at all...but does devd pick up the event at all after the restart? ( man devd on how to run devd in debug mode...) b _________________________ {Beto|Norberto|Numard} Meijome Commitment is active, not passive. Commitment is doing whatever you can to bring about the desired result. Anything less is half-hearted. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 22 16:17:55 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D9B41065676 for ; Mon, 22 Sep 2008 16:17:55 +0000 (UTC) (envelope-from Juergen.Dankoweit@t-online.de) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) by mx1.freebsd.org (Postfix) with ESMTP id 120428FC1E for ; Mon, 22 Sep 2008 16:17:55 +0000 (UTC) (envelope-from Juergen.Dankoweit@t-online.de) Received: from fwd05.aul.t-online.de by mailout10.sul.t-online.de with smtp id 1Kho6j-0005Q7-01; Mon, 22 Sep 2008 18:17:53 +0200 Received: from mail.juergendankoweit.net (bRVYgUZF8hnC3+sewpW-xy3Gc09cYUGDHMh4GvM92L6oZvkt1+CbhEpdbR1x3igwOn@[87.174.254.44]) by fwd05.aul.t-online.de with esmtp id 1Kho6H-2HORAO0; Mon, 22 Sep 2008 18:17:25 +0200 Received: from localhost (localhost.juergendankoweit.net [127.0.0.1]) by mail.juergendankoweit.net (Postfix) with ESMTP id 95451121E8; Mon, 22 Sep 2008 18:17:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at juergendankoweit.net Received: from mail.juergendankoweit.net ([127.0.0.1]) by localhost (mail.juergendankoweit.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5d4knHSSMVM; Mon, 22 Sep 2008 18:17:18 +0200 (CEST) Received: from [192.168.1.137] (t43.juergendankoweit.net [192.168.1.137]) by mail.juergendankoweit.net (Postfix) with ESMTP id E64D01218D; Mon, 22 Sep 2008 18:17:17 +0200 (CEST) From: Juergen.Dankoweit@t-online.de (=?ISO-8859-1?Q?J=FCrgen?= Dankoweit) To: Norberto Meijome In-Reply-To: <20080923011441.17751f9a@ayiin> References: <1221680202.1720.10.camel@t43.juergendankoweit.net> <20080923011441.17751f9a@ayiin> Content-Type: text/plain Date: Mon, 22 Sep 2008 18:17:17 +0200 Message-Id: <1222100237.1251.7.camel@t43.juergendankoweit.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-ID: bRVYgUZF8hnC3+sewpW-xy3Gc09cYUGDHMh4GvM92L6oZvkt1+CbhEpdbR1x3igwOn X-TOI-MSGID: ec9a93c6-796d-46fc-aa05-2a3ecd8db065 Cc: freebsd-acpi@freebsd.org Subject: Re: Thinkap T43 suspend/resume only once X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen.Dankoweit@FreeBSD-Onkel.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 16:17:55 -0000 Hello Norberto, Am Dienstag, den 23.09.2008, 01:14 +1000 schrieb Norberto Meijome: > On Wed, 17 Sep 2008 21:36:42 +0200 > Juergen Dankoweit wrote: > > > But there is one point that does not work correctly. > > When I press the Fn+F4 buttons the first time after booting the system, > > ACPI mode S3 is called correctly and the notebook goes into suspend > > mode. After pressing Fn alone the notebook resumes perfekt. > > > > But when I press Fn+F4 the next time, nothing happens. Entering > > "acpiconf -s 3" suspends the notebook and resuming is no problem > > Hi Juergen, > does any other fn- key act in a different way (well, stops working) after the first restore? I have tested this and the other keys are dead, too. After restarting the system the keys work normal. When I press Fn+F4 the suspend mode is called and the notebook switches to suspend. Pressing the Fn button brings the notebook back again and then all Fn-key-combinations are dead. When I enter acpiconf -s 3 on a console the notebook suspends and pressing Fn alone the notebook resumes and then all keys work again. To disable or enable the Bluetooth component with Fn+F5 works without any problems, when the notebook has not resumed before! Best regards Juergen From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 22 21:09:25 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 331F21065679 for ; Mon, 22 Sep 2008 21:09:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A72F08FC08 for ; Mon, 22 Sep 2008 21:09:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8ML9A91063662; Mon, 22 Sep 2008 17:09:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Oliver Peter Date: Mon, 22 Sep 2008 16:37:32 -0400 User-Agent: KMail/1.9.7 References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809091424.16302.jhb@freebsd.org> <20080922150952.GA37948@nemesis.frida.mouhaha.de> In-Reply-To: <20080922150952.GA37948@nemesis.frida.mouhaha.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809221637.33168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 22 Sep 2008 17:09:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8310/Mon Sep 22 14:58:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] 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, 22 Sep 2008 21:09:25 -0000 On Monday 22 September 2008 11:09:52 am Oliver Peter wrote: > On Tue, Sep 09, 2008 at 02:24:16PM -0400, John Baldwin wrote: > > On Monday 08 September 2008 07:08:05 pm Oliver Peter wrote: > > > ... > > > ... of course I could do that - but could you please be so kind and > > > explain how to do that? :-) > > > > Well, you could start by adding a printf to ata's interrupt handler, but that > > would result in a flood on your screen. You could maybe use a KTR instead, > > but only do it if the interrupt handler doesn't find any work to do (e.g. no > > pending request) perhaps. I think the ATA interrrupt handler already reads a > > status register of some sort, but I could be wrong. > > I feels like I need a rosetta stone for that... :) > > This is my "production" machine in the datacenter 2,000km away - > I would love to debug that interrupt storm with KTR, but I'm not sure > what I'm doing at all and nobody can ensure that my machine will > come up again after that... > > Anyway I would like to learn more about the KTR stuff. > I've never heard about that before, is that a good point to start out? > > http://www.watson.org/~robert/freebsd/netperf/ktr/ There's also a manpage (man ktr). You probably want to just enable KTR_DRIVER in KTR_COMPILE and KTR_MASK and add custom traces to the ata driver. Adding traces is about like printf: CTR0(KTR_DRIVER, "a message"); CTR1(KTR_DRIVER, "with one argument %d", foo); CTR2(KTR_DRIVER, "two args: %p (%d)", req, req->count); etc. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 23 13:10:42 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9B91065672 for ; Tue, 23 Sep 2008 13:10:42 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 446408FC13 for ; Tue, 23 Sep 2008 13:10:41 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8NCcQMZ020988 for ; Tue, 23 Sep 2008 13:38:26 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ki79u-0007Vr-96 for freebsd-acpi@FreeBSD.org; Tue, 23 Sep 2008 13:38:26 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8NCcPb5081964 for ; Tue, 23 Sep 2008 13:38:25 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8NCcPte081963 for freebsd-acpi@freebsd.org; Tue, 23 Sep 2008 13:38:25 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: freebsd-acpi@FreeBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 23 Sep 2008 13:38:25 +0100 Message-Id: <1222173505.80882.15.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: Subject: Writing a driver: how do I get resources? 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, 23 Sep 2008 13:10:42 -0000 Hi all, Please forgive me if this email makes very little sense: I've never really looked at how ACPI works from a driver's perspective, so don't really know if what I'm trying to do is even correct. I'm expanding the acpi_sony driver to cover the PNP ID SNY6001. When I simply claim it by returning 0 from the probe, I get the following I/O range: acpi_sony0: port 0-0x1f on acpi0 However, if I'm reading the AML[1] and Linux drivers[2] correctly, this is not the correct range. It appears that the _PRS method offers a choice of four I/O ranges and four IRQs, one of which is then selected by evaluating _SRS. None of them are 0-0x1f. Firstly, does that make sense? Secondly, how do I do this from a driver? I can't see any other drivers that seem to get this involved in ACPI, indeed the only mention of evaluating _PRS is within the ACPI code itself. Lastly, I only have intermittent access to this laptop, so I apologise if I can't test things quickly. Thanks, Gavin [1] http://www-users.york.ac.uk/~ga9/sony-vgn-tz31wn.asl [2] http://lxr.linux.no/linux+v2.6.26.5/drivers/misc/sony-laptop.c From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 23 15:23:50 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7611065679; Tue, 23 Sep 2008 15:23:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6E558FC08; Tue, 23 Sep 2008 15:23:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NFNgBi073166; Tue, 23 Sep 2008 11:23:43 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 23 Sep 2008 10:36:59 -0400 User-Agent: KMail/1.9.7 References: <1222173505.80882.15.camel@buffy.york.ac.uk> In-Reply-To: <1222173505.80882.15.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231037.00392.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 11:23:43 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8316/Tue Sep 23 05:40:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Gavin Atkinson Subject: Re: Writing a driver: how do I get resources? 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, 23 Sep 2008 15:23:50 -0000 On Tuesday 23 September 2008 08:38:25 am Gavin Atkinson wrote: > Hi all, > > Please forgive me if this email makes very little sense: I've never > really looked at how ACPI works from a driver's perspective, so don't > really know if what I'm trying to do is even correct. > > I'm expanding the acpi_sony driver to cover the PNP ID SNY6001. When I > simply claim it by returning 0 from the probe, I get the following I/O range: > > acpi_sony0: port 0-0x1f on acpi0 > > However, if I'm reading the AML[1] and Linux drivers[2] correctly, this > is not the correct range. It appears that the _PRS method offers a > choice of four I/O ranges and four IRQs, one of which is then selected > by evaluating _SRS. None of them are 0-0x1f. > > Firstly, does that make sense? Secondly, how do I do this from a > driver? I can't see any other drivers that seem to get this involved in > ACPI, indeed the only mention of evaluating _PRS is within the ACPI code > itself. > > Lastly, I only have intermittent access to this laptop, so I apologise > if I can't test things quickly. Our ACPI driver isn't smart enough yet (AFAIK) to allocate new resources for a device that doesn't have any. That logic should be in acpi_alloc_resource() and once that is present then your driver just needs to do the usual bus_alloc_resource() stuff to work. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 23 17:21:26 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E16E1065679; Tue, 23 Sep 2008 17:21:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id A768D8FC13; Tue, 23 Sep 2008 17:21:25 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id m8NHLNi4009995; Tue, 23 Sep 2008 18:21:23 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KiBZj-0003fC-Iu; Tue, 23 Sep 2008 18:21:23 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m8NHLNbo084548; Tue, 23 Sep 2008 18:21:23 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m8NHLNab084547; Tue, 23 Sep 2008 18:21:23 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: John Baldwin In-Reply-To: <200809231037.00392.jhb@freebsd.org> References: <1222173505.80882.15.camel@buffy.york.ac.uk> <200809231037.00392.jhb@freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 23 Sep 2008 18:21:22 +0100 Message-Id: <1222190482.80882.28.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-acpi@FreeBSD.org Subject: Re: Writing a driver: how do I get resources? 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, 23 Sep 2008 17:21:26 -0000 On Tue, 2008-09-23 at 10:36 -0400, John Baldwin wrote: > On Tuesday 23 September 2008 08:38:25 am Gavin Atkinson wrote: > > Hi all, > > > > Please forgive me if this email makes very little sense: I've never > > really looked at how ACPI works from a driver's perspective, so don't > > really know if what I'm trying to do is even correct. > > > > I'm expanding the acpi_sony driver to cover the PNP ID SNY6001. When I > > simply claim it by returning 0 from the probe, I get the following I/O > range: > > > > acpi_sony0: port 0-0x1f on acpi0 > > > > However, if I'm reading the AML[1] and Linux drivers[2] correctly, this > > is not the correct range. It appears that the _PRS method offers a > > choice of four I/O ranges and four IRQs, one of which is then selected > > by evaluating _SRS. None of them are 0-0x1f. > > > > Firstly, does that make sense? Secondly, how do I do this from a > > driver? I can't see any other drivers that seem to get this involved in > > ACPI, indeed the only mention of evaluating _PRS is within the ACPI code > > itself. > > > > Lastly, I only have intermittent access to this laptop, so I apologise > > if I can't test things quickly. > > Our ACPI driver isn't smart enough yet (AFAIK) to allocate new resources for a > device that doesn't have any. That logic should be in acpi_alloc_resource() > and once that is present then your driver just needs to do the usual > bus_alloc_resource() stuff to work. Thanks. So I guess there's no easy way to do it at the moment? Gavin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 23 19:12:16 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724451065671; Tue, 23 Sep 2008 19:12:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3A638FC0C; Tue, 23 Sep 2008 19:12:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NJC9Vn074798; Tue, 23 Sep 2008 15:12:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Gavin Atkinson Date: Tue, 23 Sep 2008 14:12:50 -0400 User-Agent: KMail/1.9.7 References: <1222173505.80882.15.camel@buffy.york.ac.uk> <200809231037.00392.jhb@freebsd.org> <1222190482.80882.28.camel@buffy.york.ac.uk> In-Reply-To: <1222190482.80882.28.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231412.50418.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 15:12:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8316/Tue Sep 23 05:40:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: Writing a driver: how do I get resources? 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, 23 Sep 2008 19:12:16 -0000 On Tuesday 23 September 2008 01:21:22 pm Gavin Atkinson wrote: > On Tue, 2008-09-23 at 10:36 -0400, John Baldwin wrote: > > On Tuesday 23 September 2008 08:38:25 am Gavin Atkinson wrote: > > > Hi all, > > > > > > Please forgive me if this email makes very little sense: I've never > > > really looked at how ACPI works from a driver's perspective, so don't > > > really know if what I'm trying to do is even correct. > > > > > > I'm expanding the acpi_sony driver to cover the PNP ID SNY6001. When I > > > simply claim it by returning 0 from the probe, I get the following I/O > > range: > > > > > > acpi_sony0: port 0-0x1f on acpi0 > > > > > > However, if I'm reading the AML[1] and Linux drivers[2] correctly, this > > > is not the correct range. It appears that the _PRS method offers a > > > choice of four I/O ranges and four IRQs, one of which is then selected > > > by evaluating _SRS. None of them are 0-0x1f. > > > > > > Firstly, does that make sense? Secondly, how do I do this from a > > > driver? I can't see any other drivers that seem to get this involved in > > > ACPI, indeed the only mention of evaluating _PRS is within the ACPI code > > > itself. > > > > > > Lastly, I only have intermittent access to this laptop, so I apologise > > > if I can't test things quickly. > > > > Our ACPI driver isn't smart enough yet (AFAIK) to allocate new resources for a > > device that doesn't have any. That logic should be in acpi_alloc_resource() > > and once that is present then your driver just needs to do the usual > > bus_alloc_resource() stuff to work. > > Thanks. So I guess there's no easy way to do it at the moment? No. :( What you would need to do is to change acpi_alloc_resource() such that if it is working on a direct child (so device_get_parent(child) == dev) and the child has no resources assigned yet, but there are possible resources, it needs to allocate a set of resources and do _SRS. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 23 19:47:36 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05A6E106567F; Tue, 23 Sep 2008 19:47:36 +0000 (UTC) (envelope-from nate@root.org) Received: from fulgencio.claresco.com (209-128-117-004.BAYAREA.NET [209.128.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id D8EF58FC31; Tue, 23 Sep 2008 19:47:35 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.1.144] (fw.claresco.com [209.128.117.3]) by fulgencio.claresco.com (Postfix) with ESMTP id A3D661339B6; Tue, 23 Sep 2008 11:05:58 -0700 (PDT) Message-ID: <48D93006.7050400@root.org> Date: Tue, 23 Sep 2008 11:05:58 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Gavin Atkinson References: <1222173505.80882.15.camel@buffy.york.ac.uk> In-Reply-To: <1222173505.80882.15.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Writing a driver: how do I get resources? 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, 23 Sep 2008 19:47:36 -0000 Gavin Atkinson wrote: > Please forgive me if this email makes very little sense: I've never > really looked at how ACPI works from a driver's perspective, so don't > really know if what I'm trying to do is even correct. > > I'm expanding the acpi_sony driver to cover the PNP ID SNY6001. When I > simply claim it by returning 0 from the probe, I get the following I/O range: > > acpi_sony0: port 0-0x1f on acpi0 > > However, if I'm reading the AML[1] and Linux drivers[2] correctly, this > is not the correct range. It appears that the _PRS method offers a > choice of four I/O ranges and four IRQs, one of which is then selected > by evaluating _SRS. None of them are 0-0x1f. > > Firstly, does that make sense? Secondly, how do I do this from a > driver? I can't see any other drivers that seem to get this involved in > ACPI, indeed the only mention of evaluating _PRS is within the ACPI code > itself. Generally resources are the responsibility of the parent bus. So for various devices (ethernet, usb, etc.) attached to a pci bus, the acpi_pci driver sets up the resources correctly for them. The Sony driver is somewhat special in that it's not on a standard bus, it's proprietary. Same goes for the IBM, Panasonic, etc. power management drivers. For Windows, the OEM even writes this driver, not Microsoft. Since there's no parent bus, the driver itself has to set up its resources. You're seeing that this is just not being done. Normally the BIOS initializes such devices with reasonable values, but in your case it hasn't. FreeBSD does not yet have support routines for _SRS (set resources). For non-standard devices, we just use _CRS (current resources) and trust that the BIOS set things up well. Obviously, it would be good to have some conversion routine that read _CRS and _PRS and provided a bus method to wrap _SRS. Then all these proprietary drivers could ask for resources in a common way. This would be the FreeBSD Approach. The Linux approach is to cut/paste the low-level routines into each driver (this time from the PCI driver) and have them grok ACPI resources directly. This is not a good approach but is the one the Linux sony-laptop driver takes. If you talk to John Baldwin, he may have some ideas how to implement _SRS support in a general way. I'm sure he'd love the help. If you don't want to do that, you'll have to implement methods similar to the Linux sony_pic_add(), sony_pic_enable(), etc. in the FreeBSD acpi_sony.c driver. This might still be a useful first step to understand how to generalize these routines. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 24 03:58:52 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A87106566C for ; Wed, 24 Sep 2008 03:58:52 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1E42E8FC0C for ; Wed, 24 Sep 2008 03:58:51 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id m8O3ZZFx023227 for ; Wed, 24 Sep 2008 13:05:35 +0930 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 24 Sep 2008 13:07:22 +0930 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 13:37:22 +1000 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by stlex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Sep 2008 11:37:21 +0800 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.2/8.14.2) with ESMTP id m8O3ZcPB011650 for ; Wed, 24 Sep 2008 11:35:38 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.2/8.14.2/Submit) id m8O3ZckP011649 for freebsd-acpi@freebsd.org; Wed, 24 Sep 2008 11:35:38 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 24 Sep 2008 11:35:38 +0800 From: "Wilkinson, Alex" To: freebsd-acpi@freebsd.org Message-ID: <20080924033538.GE9790@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-acpi@freebsd.org References: <1222173505.80882.15.camel@buffy.york.ac.uk> <48D93006.7050400@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <48D93006.7050400@root.org> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 24 Sep 2008 03:37:21.0629 (UTC) FILETIME=[DA2CA8D0:01C91DF6] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.5.1027-16174.007 X-TM-AS-Result: No-6.156300-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: Writing a driver: how do I get resources? 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, 24 Sep 2008 03:58:52 -0000 0n Tue, Sep 23, 2008 at 11:05:58AM -0700, Nate Lawson wrote: >The Sony driver is somewhat special in that it's not on a standard bus, >it's proprietary. Same goes for the IBM, Panasonic, etc. power >management drivers. For Windows, the OEM even writes this driver, not >Microsoft. What are the best laptops to use with freebsd then ? i.e the ones that dont have a proprietary bus ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 24 04:44:12 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5CA1065672 for ; Wed, 24 Sep 2008 04:44:12 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5682B8FC1E for ; Wed, 24 Sep 2008 04:44:04 +0000 (UTC) (envelope-from nate@root.org) X-ORBL: [71.139.1.181] Received: from [10.0.5.18] (ppp-71-139-1-181.dsl.snfc21.pacbell.net [71.139.1.181]) by nlpi087.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m8O4i3tr018338 for ; Tue, 23 Sep 2008 23:44:04 -0500 Message-ID: <48D9C592.4050103@root.org> Date: Tue, 23 Sep 2008 21:44:02 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <1222173505.80882.15.camel@buffy.york.ac.uk> <48D93006.7050400@root.org> <20080924033538.GE9790@stlux503.dsto.defence.gov.au> In-Reply-To: <20080924033538.GE9790@stlux503.dsto.defence.gov.au> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Writing a driver: how do I get resources? 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, 24 Sep 2008 04:44:12 -0000 Wilkinson, Alex wrote: > 0n Tue, Sep 23, 2008 at 11:05:58AM -0700, Nate Lawson wrote: > > >The Sony driver is somewhat special in that it's not on a standard bus, > >it's proprietary. Same goes for the IBM, Panasonic, etc. power > >management drivers. For Windows, the OEM even writes this driver, not > >Microsoft. > > What are the best laptops to use with freebsd then ? i.e the ones that dont have > a proprietary bus ? You misunderstood. What I'm saying is that all laptops have proprietary OEM drivers for features like hotkeys, backlight, etc. That includes Acer, IBM/Lenovo, Toshiba, Panasonic, Sony, etc. The "hardware" you're accessing via those ACPI methods is actually the BIOS itself, which then talks to the chipset and GPIO pins to perform the requests. So there's no PCI bus or other open interface to configure these. Your best bet is to implement the _SRS stuff the way John was suggesting. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 25 02:26:49 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28A021065696; Thu, 25 Sep 2008 02:26:49 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0099F8FC17; Thu, 25 Sep 2008 02:26:49 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8P2Qmqw080523; Thu, 25 Sep 2008 02:26:48 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8P2QmMA080519; Thu, 25 Sep 2008 02:26:48 GMT (envelope-from gavin) Date: Thu, 25 Sep 2008 02:26:48 GMT Message-Id: <200809250226.m8P2QmMA080519@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/127581: [patch] [acpi_sony] Add support for more Sony features 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: Thu, 25 Sep 2008 02:26:49 -0000 Synopsis: [patch] [acpi_sony] Add support for more Sony features Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: gavin Responsible-Changed-When: Thu Sep 25 02:26:16 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=127581 From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 25 17:25:12 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF1EB106568B for ; Thu, 25 Sep 2008 17:25:12 +0000 (UTC) (envelope-from Jahanshah_Rashidian@gmx.de) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 93C5F8FC1C for ; Thu, 25 Sep 2008 17:25:12 +0000 (UTC) (envelope-from Jahanshah_Rashidian@gmx.de) Received: from 2ao1z ([98.26.230.206]) by hrndva-omta01.mail.rr.com with ESMTP id <20080925170943.JHJT12744.hrndva-omta01.mail.rr.com@2ao1z> for ; Thu, 25 Sep 2008 17:09:43 +0000 From: "Jahanshah Rashidian" To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset="US-ASCII" Date: Thu, 25 Sep 2008 19:09:49 +0200 X-Priority: 3 Message-Id: <20080925170943.JHJT12744.hrndva-omta01.mail.rr.com@2ao1z> Cc: Subject: The Walls of Auschwitz X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jahanshah_Rashidian@gmx.de List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 17:25:13 -0000 The Walls of Auschwitz A Review of the Chemical Studies by Nicholas Kollerstrom, PhD In his essay, Dr Nicholas Kollerstrom argues that the alleged massacre of Jewish people by gassing during World War II was scientifically impossible. The distinguished academic was dismissed on April 22, 2008 without any explanation and a Holocaust conference held on 16-18 May in Berlin refused his article and warned that he would be arrested if he attended the conference and presented his essay. The West punishes people for their scientific research on Holocaust but the same western countries allow insults to prophets and religious beliefs… I. The Leuchter Report, 1988 In February 1988, Fred Leuchter came to the Auschwitz crematoria ruins, with his wife and a team, and took 32 samples chiseled out of the wall. His Report published in April of 1998 contained five maps as appendices which indicated where the samples had been taken from, and in addition a film was made of his sampling'. The locations are important, because some of the 'gas chamber' locations are postwar-reconstructed, and the obtaining of original brickwork was essential for his purpose. Leuchter in effect tested the hypothesis, as to whether or not certain large rooms, designated in the Auschwitz design-plans as either morgues or washrooms, had in fact been used for large-scale human cyanide gassing on a daily and lethal basis. As America's only professional cyanide-gas execution expert, Leuchter was primarily concerned with whether it would have been feasible to perform such executions using the designated rooms; this however will not concern us here, our concern being solely with the wall samples he took. These were analyzed in March 1988 by Alpha Analytical Laboratories Ltd, in ignorance of their source. He managed to take one one sample of a 'Disinfestation Chamber,' by breaking and entering a locked building: but prowling guards and snowy blizzards prevented further sampling from a second such chamber at camp Majdanek . His swiftly-published 'Report' in effect grouped his data into two, that of the sample 32 which he called perhaps unfortunately his 'control,' and all the others, as the graph shows. The latter came from five 'Crematoria' sites in the Auschwitz complex. Duality of the 'Gas Chamber' concept in Leuchter's Report The terms that will here be used, that are as far as possible non-judgmental, are AHGCs or alleged human gas chambers for what Leuchter called 'Crematoria' and DCs or disinfestation chambers for what in the German design-plans were called 'gas chambers' (gaskammers). The latter had been used in Germany since 1924, much as we would ?nowadays use DDT, for killing the flea that carried the typhus bacillus. They were operated using 'Zyklon-B' granules, composed of liquid hydrogen cyanide (boiling-point 27° C) that would evaporate over a couple of hours from its clay substrate. In the German labor-camps, clothing and bedding were repeatedly fumigated in such chambers. Prior to Leuchter's work, pro - Holocaust books had not acknowledged such chambers, and had rather carried the message of the Nuremberg trials, whereby any use of Zyklon-B was merely presumed to have been for human extermination. After Leuchter, Pressac's magnum opus reproducing design-plans of Auschwitz-Birkenau located and described the 'Gaskammer' or DCs . These were quite a lot smaller than the AHGCs, and designed by the industrial-chemistry firm 'Degesh.' Pressac also observed that their walls tended to be blue: they had gradually developed that hue after the War, owing to their saturation with iron-cyanide. Fred Leuchter found one thousand -fold difference in residual cyanide levels between these two types of 'gas chamber' - that designated in German design-plans as gas chambers but whose existence was ignored at Nuremberg, and the much larger rooms alleged to have functioned as gas chambers. Together with Pressac's acknowledgement of the DCs, this meant that all future pro-Holocaust books had to work with a duality: that the very same cans of ' Zyklon-B' were used for two extremely different purposes on the same campsite: for taking lives via the extermination procedure, whereby millions died, in the extraordinary manner described at Nuremberg, and also for saving them by combating the typhus epidemic. This did not make a great deal of sense and some noted that one could more readily have not bothered and just let the typhus epidemic do its work. There was controversy over the extent to which all of Leuchter's samples had indeed been taken from walls of chambers allegedly exposed to the cyanide, given that much of the 'gas chambers' are now acknowledged to be postwar-reconstructed; as likewise there was disagreement over the extent to which exposed walls may have had any cyanide leeched out from them over six decades, a theme we return later on with the work of Mr Dan Desjardins. The iron-cyanide bonding which takes place once the HCN has entered the brick and mortar of the walls, is permanent: the complex ferric ferrocyanide otherwise known as "Iron Berlinate" or "Prussian Blue" is, according to The Merck Index, " ... practically insoluble in water." It is used as a pigment in printing inks and artists' colors, and remains stable in water, air, ultraviolet radiation and with the elevated temperatures of summer. Following Leuchter's discovery, some suggested that the DCs had been more heavily used than the AHGCs, after all did not beetles or fleas take longer to kill than humans? And, were not the DCs heated in order to promote the release of the HCN, and would that not give a higher degree of wall-absorption? Others replied that, if half a million people had allegedly been gassed in 'Krema I' over a two-year or so period then that would have been a rather intensive use, and not easily reconcilable with Alpha Analytical Laboratory's finding that all seven wall-samples taken therefrom had total cyanide too low to be measurable. Should not all the moisture from the body sweat have rather promoted HCN absorption? Others had a different criticism, that the cyanide gas would have only been adsorbed onto the wall surface, and that the concentrations found would to a large extent merely reflect the extent to which surface material of the wall had been scraped off, while deeper samples would hardly contain any. We leave these questions for now and review the two further chemical investigations, performed in the wake of Leuchter. II. The Rudolf Report, 1993 …fortunately it is precisely the one 'gas chamber' in which the largest number of people was allegedly killed by poison gas during the Third Reich which has remained almost entirely intact: morgue 1 of crematorium II' Germar Rudolf Germar Rudolf found that the Leuchter Report 'embedded the thorn of doubt in my heart' while he was a PhD chemist at the prestigious Max Plank Institute. In 1991 he visited Auschwitz and took 24 samples, analyzed by the Fresenius Institute using a comparable procedure. He was later criticized for having used the Max Plank Institute notepaper for having asked them to do this, without explaining where they had been taken from. Both Leuchter and Rudolf used their professional position to request the chemical analysis, and both had their professional existence terminated by that act. Although Rudolf's sample-taking was photographed, he was criticized for not having had enough by way of witnesses checking his sample-taking and how the containers were labeled for his thirty-odd samples. Both Leuchter and Rudolf took their samples without having obtained permission - which assuredly would not have been given, had they asked. The samples were boiled for an hour with hydrochloric acid to drive out the cyanide gas, collected by absorption with caustic potash, then assayed photometrically. ?The method gave cyanide levels down to 0.1 - 0.2 ppm in the mortar, obtaining measurable values for almost all of his samples, despite which Rudolf remained doubtful over the value and reproducibility of results below several parts per million He sampled extensively both from the inside and outside of the blue-stained DCs at Birkenau, where his grouped results were: Table 1: Mean Cyanide DC Birkenau wall-sample values, Germar Rudolf data, 1991 De-lousing room, inside: 5830 ± 3700 ppm (n=l0) outside: 3010 ± 3600 ppm (n=5) This indicates that the cyanide gas was able to penetrate right through the brick walls, and would not merely have been adsorbed onto the surface; and suggests that weathering over half a century has not greatly affected the cyanide concentrations. This data has a central importance, because Leuchter had only managed to take one single sample of de-lousing chamber wall. The 'Control' samples of Germar Rudolf Rudolf only took three samples from the AHGC walls (from what is called the Krema-II morgue), which was the weakness of his survey. Their wide divergences (7.2, 0.6 and 6.7 ppm) give little idea of this key parameter!". He took more samples from 'controls' - i.e., rooms where no-one had alleged that systematic cyanide gassing had taken place. His 'control' group is here subdivided into samples taken from the mortar between the bricks, and the rest. Table 2: As before, sampling AHGC walls vs 'controls' AHGC walls 4.8 ± 3 ppm (n=3) His samples 1-3 of Table 19. Controls, plaster: 1.1± 1.3 ppm (n=6) His samples 4,5,7,8, 10,23. Controls, mortar: 0.2± 0.1 (n=3) Samples 6,21,24 This indicates a significant elevation of residual cyanide in the AHGCs. The Ball Report 1993 It is hard to obtain copies of this Report, or to gain details of where the chemical analysis was performed'". J.C. Ball has a degree in geology, and worked as a mineral exploration geologist. Given the intensity of criticism to which anyone publishing in this area is exposed, one should perhaps refrain from criticism on this matter. Its six samples were: Table 3: Mean values of the cyanide measurements found by John Ball, 1993 >From a DC 3000 ppm (n=2) 11.The Rudolf Report, 8.3.3, Table 19; also Table 3 in 'Dissecting the Holocaust' Chapter by GR. 12. Dissecting the Holocaust 2003 http://vho.orglGB/Books/dth/fndgcger.html Table 3 ofRudolfCh. 13. For his difficulties here, see: www.ihr.orglleaflets/inside.shtml 14. Table 19, p254 of The Rudolf Report 2001. 15. John Clive Ball, The Ball Report, Ball Resource Services Ltd., Canada 1993; The Rudolf Report, p.268. ? >From AHGC sites 0.5 ± 0.6 (n=4) ppm III. The Markiewicz et. al. Polish Study of 1994 The manager of Auschwitz Mr Piper approached Dr Jan Markiewicz of the Jan Sehn Institute of Forensic Research at Cracow as to whether they would check over the residual cyanide levels, in the wake of the Leuchter Report. On 20 Feb 1990 Dr. Wojciech Gubala arrived and removed 22 samples, including two control samples. The team then decided that they would like to follow this up with a further study before publishing any results. This survey, published in 1994, differed from those of Leuchter and Rudolf in that it only looked at soluble cyanide in the brickwork. Critics objected that it was precisely the soluble component of cyanide which one would not expect to provide a memory of the past, because it would clearly be affected by weathering. Their reason for using such a method, was apparently that they did not want to get involved in debates over Prussian Blue formation: their approach 'excludes the possibility of the decomposition of the relatively permanent Prussian blue, whose origin is unclear in many parts of the structures under investigation,' and therefore 'The real level of total cyanide compounds could therefore be higher than shown by our analysis.' The samples were put in 10% sulphuric acid for 24 hours, thereby driving off the cyanide as before, except that cyanide bonded to iron was not liberated by the Polish method - the point of which has not been clear to a lot of people. The soluble or non-bonded cyanide thereby measured was only present in low concentrations measured in parts per billion rather than parts per million. How were they able to attain this accuracy in measurement unattainable either by Alpha Analytical laboratories or the Fesenius Institute? The method they referenced for this analysis had been published in 1947, and could one expect this to attain these much higher levels of accuracy? From three 'gas chambers' they found: Table IV: Polish data, Mean levels of soluble cyanide in Crematoria walls. 1994 AHGC walls, Krema I: 0.07 ± 0.1 ppm (n=7) KremaII: 0.16 ± 0.2 ppm (n=7) Krema III: 0.03 ± 0.02 ppm (n=7) These samples averaged 90 parts per billion. The Polish group claimed that their method could measure down to 2-3 parts per billion. For their 'control' they took eight samples from three different residential blocks, and thereby obtained (or at least published) consistently zero values - i.e., zero parts per billion! How impressive to have discovered this ultra-sensitive method. As 'holocaust' chemist Dr Richard Green explained, 'The IFFR used a much more sensitive method. Their sensitivity was 3-4/!g/kg, i.e., 300 times more sensitive.' If that method published in 1947 had such astounding accuracy, then why did subsequent chemists fail to use it? This investigation gave DC wall-concentrations in its Table 4, finding a several-fold elevation in cyanide levels there. Eight values for 'concentrations of cyanide ions in samples collected in the facilities for the fumigation of prisoners clothes, (Birkenau BathHouse Camp BI-A)' gave a mean value of273 ppb, thrice that of the 'Kremas.' Their conclusion omitted comment upon this highly significant elevation. This paper has been much cited by pro-Holocaust sources, as refuting the Leuchter Report, by demonstrating that the AHGCs ('Kremas') had raised cyanide as compared to 'controls.' The paper was entitled, 'A study of the cyanide compound contents in the walls of the gas chambers in the former Auschwitz and Birkenau concentration camps'. It thus used a Nuremberg-type terminology, where 'gas chamber' simply meant a place for human extermination. They could hardly have done otherwise, because doubt over 'the Holocaust' is a crime in Poland. The DCs were alluded to as 'Facilities For the Fumigation of Prisoners' Clothes.' The Polish team went to a lot of trouble, with some sixty measurements mostly measured thrice, and was the only study which obtained permission to take the samples. It omitted two things in its conclusions: any allusion to the Birkenau DC ('facilities for the fumigation of prisoners' clothes') where it had found greatly-elevated cyanide levels over the AHGCs; and, the insoluble cyanide that was bound to iron. In regard to both of these it cited the Prussian blue ferric ferrocyanide complex, leaving open the possibility that is had some quite extraneous source and was therefore to be avoided. The 1947 method used by Markiewicz et. al. was given by Joseph Epstein and published in a US chemistry journal." It was a procedure whose limit of accuracy was given as 0.2 micrograms per ml. To expel the cyanide from brickwork and then dissolve it into a solution suitable for measuring it, involves an order-of-magnitude dilution at least, so that one would not expect to obtain an accuracy less then one ppm in the brickwork, using this method. Any claim that this decades-old titration and colorimetric method using thiocyanate can find parts per billion has to be spurious. IV. Desjardin analyses Leuchter Dan Desjardins, after carefully retracing the steps of Leuchter on a 1996 visit to Auschwitz'", and watching the film that had been made of Leuchter's sampling'", divided the samples 1-31 into two groups: those which had been exposed and open to the elements over the decades (n=20), and those which were more protected in sheltered, unexposed locations: 'Leuchter's samples, numbered 25 through 31, extracted from Crematorium I... taken from a facility which was not destroyed and has remained intact since the end of the war, were not exposed to the elements. The same might be said for samples 4, 5 and 6 taken from Crematorium II. Leuchter removed these samples from a pillar, wall and ceiling which, though accessible, were nevertheless well protected against wind, rain and sun.' Less then half (14 out of 35) of Leuchter's samples had measurable levels of cyanide in them, where measurable means above one part per million. We have here assigned an arbitrary value of 0.5 ppm for those too low to measure, i.e below 1 ppm. This gave: Table 5: Desjardins grouping of the Leuchter data as 'sheltered' or 'exposed' (2007) Sheltered (n=l0) 1.88 ± 2.2 ppm Exposed (n=20) 1.31 ± 1.56 ppm The 'exposed' group scored 30% lower than the sheltered group, a result which lacks statistical significance (t=0.8). This data could suggest that one-third of the cyanide had leeched out from the exposed walls, over sixty years; if indeed they had all at one historic period been exposed to hydrogen cyanide. Mr Desjardins further subdivided the Leuchter samples into those taken from AHGC walls, and those which were 'controls' i.e taken from barracks, etc. The definition of the 'control' concept is critical here, and means brickwork where no one has been concerned to allege that is was part of a room where systematic cyanide gassing took place whether of humans or of mattresses. Leuchter surmised that the 'control' sample had been exposed at some stage to a single fumigation by cyanide gas, by way of cleaning out any lice from cracks etc. Table 6: Desjardins groups Leuchter's data by AHGC versus 'controls' AHGCs (n=19) 1.63 ± 2.1 ppm Controls (n=9) 1.45 ± 1.2 ppm This result too lacks statistical significance, i.e. Leuchter's sample provides no evidence for human 'gas chambers' having raised residual cyanide levels above those of 'controls.' The data suggests that the AHGCs did not ever function as lethal gas chambers. These two sets of data (using Desjardins' divisions) covary somewhat, in that if we increase the 'exposed' samples by say 25%, to allow for leeching out of their cyanide over the decades, then the difference between the AHGC and 'control' groups disappears altogether. (As Mr Desjardins put it, five times as many of these [AHGC] samples came from locations protected from 40-years' exposure to wind and rain.') Mr Desjardins concluded, 'Fred Leuchter's broad sample gathering, despite flaws, establishes a reasonable basis for inferring that the presence of cyanide residue is due to benign rather than homicidal purposes. Conclusions 1. One might expect that the accuracy of cyanide-ion assay would have increased substantially over the last couple of decades, but this is not the case: any reanalysis of the brickwork would face the same frustrating situation, where differences between AHGCs and controls hover right next to the lowest detectable levels. 2. The essential questions here reviewed may be best evaluated without arguments over whether or not Prussian blue coloration has formed. The latter involves a slow and complex sequence of reactions. We have here been primarily concerned with total cyanide in the brickwork. 3. Plaster on the wall-surface may tend to have a higher cyanide level than brick or mortar underneath it, and the ferric-ferrocyanide does decrease as a function of depth. Samples should therefore aim to have a comparable breadth-to-depth ratio. 4. The notion of a 'control' sample has developed from Rudolf's sampling and also from Mr. Desjardins evaluation of the Leuchter sample locations. This permitted an evaluation of whether measurements of authentic AHGC wall were significantly elevated over such. While there was a hint of this from Rudolf's sampling, and while further investigation might confirm this, overall no statistically significant elevation was evident. 5. The careful and extensive Polish data was analyzed using a 1947 US titration procedure, which gave no indication of reaching the parts per billion accuracy claimed by that study. If Marciewicz et. al chose to use a method which only analyzed 1 % or less of the cyanide, viz. the soluble component, for whatever reason, they should first have shown that their method was capable of detecting it. 6. Both the Leuchter and Rudolf surveys obtained a three order-of-magnitude differential between the walls of DC and AHGC buildings; the simplest explanation of which is that the former was used on a regular basis for cyanide fumigation while the latter was not. 7. The Leuchter data showed that there was no great diminution of cyanide levels due to weathering over half a century, and this accords with what is known about the insolubility and permanence of the ferric-ferrocyanide complex. The residual cyanide within those walls may therefore offer the most reliable memory which the human race now has, concerning what happened historically in German 'gas chambers.' Source: http://www.presstv.com/Detail.aspx?id=56287§ionid=3510303 ------------------------------------------------------------------------------ To unsubscribe from our mailing list, please send an email to Jahanshah_Rashidian@gmx.de Jahanshah Rashidian From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 26 19:49:56 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7DE9106564A for ; Fri, 26 Sep 2008 19:49:56 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 950448FC1F for ; Fri, 26 Sep 2008 19:49:56 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 26 Sep 2008 12:46:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,316,1220252400"; d="scan'208";a="384834410" Received: from unknown (HELO azsmsx601.amr.corp.intel.com) ([10.2.121.193]) by fmsmga002.fm.intel.com with ESMTP; 26 Sep 2008 12:46:45 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.226.213) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 26 Sep 2008 12:49:55 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Fri, 26 Sep 2008 12:49:54 -0700 From: "Moore, Robert" To: "Moore, Robert" Date: Fri, 26 Sep 2008 12:49:53 -0700 Thread-Topic: ACPICA version 20080926 released Thread-Index: AckgEQsXzT9EbcgZQl+UqGPzDGuu6w== Message-ID: <4911F71203A09E4D9981D27F9D83085876770B@orsmsx503.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 26 Sep 2008 19:52:58 +0000 Cc: Subject: ACPICA version 20080926 released 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, 26 Sep 2008 19:49:56 -0000 26 September 2008. Summary of changes for version 20080926: This release is available at www.acpica.org/downloads. 1) ACPI CA Core Subsystem: Designed and implemented a mechanism to validate predefined ACPI methods an= d objects. This code validates the predefined ACPI objects (objects whose n= ames start with underscore) that appear in the namespace, at the time they = are evaluated. The argument count and the type of the returned object are v= alidated against the ACPI specification. The purpose of this validation is = to detect problems with the BIOS-implemented predefined ACPI objects before= the results are returned to the ACPI-related drivers. Future enhancements = may include actual repair of incorrect return objects where possible. Two n= ew files are nspredef.c and acpredef.h. Fixed a fault in the AML parser if a memory allocation fails during the Op = completion routine AcpiPsCompleteThisOp. Lin Ming. ACPICA BZ 492. Fixed an issue with implicit return compatibility. This change improves the= implicit return mechanism to be more compatible with the MS interpreter. L= in Ming, ACPICA BZ 349. Implemented support for zero-length buffer-to-string conversions. Allow zer= o length strings during interpreter buffer-to-string conversions. For examp= le, during the ToDecimalString and ToHexString operators, as well as implic= it conversions. Fiodor Suietov, ACPICA BZ 585. Fixed two possible memory leaks in the error exit paths of AcpiUtUpdateObje= ctReference and AcpiUtWalkPackageTree. These functions are similar in that = they use a stack of state objects in order to eliminate recursion. The stac= k must be fully unwound and deallocated if an error occurs. Lin Ming. ACPIC= A BZ 383. Removed the unused ACPI_BITREG_WAKE_ENABLE definition and entry in the glob= al ACPI register table. This bit does not exist and is unused. Lin Ming, Bo= b Moore ACPICA BZ 442. Removed the obsolete version number in module headers. Removed the "$Revisi= on" number that appeared in each module header. This version number was use= ful under SourceSafe and CVS, but has no meaning under git. It is not only = incorrect, it could also be misleading. Example Code and Data Size: These are the sizes for the OS-independent acpi= ca.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug = version of the code includes the debug output trace mechanism and has a muc= h larger code and data size. Previous Release: Non-Debug Version: 79.7K Code, 16.4K Data, 96.1K Total Debug Version: 153.7K Code, 48.2K Data, 201.9K Total Current Release: Non-Debug Version: 81.2K Code, 17.0K Data, 98.2K Total Debug Version: 155.8K Code, 49.1K Data, 204.9K Total From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 27 15:47:00 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D97D106568B for ; Sat, 27 Sep 2008 15:47:00 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1501A8FC14 for ; Sat, 27 Sep 2008 15:47:00 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail52.abv.bg (mail52.ni.bg [192.168.151.19]) by smtp-out.abv.bg (Postfix) with ESMTP id 7742887AAD for ; Sat, 27 Sep 2008 18:27:11 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=X9btrFoJczV9Rr+OAx1pr9UGsWMZfxZPCWPMOnhB4fUaybO9pQOuTg5h/SC7PiXMj 6A5EKbr4N/8lDoYkckWjt+206dt8fnKuNgiO2yIwYZsG5WVmEOtTP3Bvnm/iqLPWK2Y d9Axy67/2tO/WaVDOyc50ryyxRir/d9yaZ7UNjI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1222529231; bh=yWqC/D/lm9oYjpxWR7GBv++g/xC2zBTE2n1T/dyYrwc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=tkbIlcYTbdA8yJOs0I/Squ8SuoGuIu+N 6iJxq0A8S1qWfWW+gAoh3BsVwoDL3Mb9PbGh+QVQ13OiwIvrTtcHzZkVnfwFsQVc2Gs fEns6Z5AqLqGtcgpCtIgXMyYeUDOMLsSC4H3kXK34lsxCiC7I+jboi/9VE318GkTjZ2 OvBZY= Received: from mail52.abv.bg (mail52.abv.bg [127.0.0.1]) by mail52.abv.bg (Postfix) with ESMTP id A29AB1ACA63 for ; Sat, 27 Sep 2008 18:27:10 +0300 (EEST) Date: Sat, 27 Sep 2008 18:27:10 +0300 (EEST) From: Mario Pavlov To: freebsd-acpi@freebsd.org Message-ID: <2079751158.340791.1222529230663.JavaMail.apache@mail52.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Subject: Re: ACPICA version 20080926 released 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: Sat, 27 Sep 2008 15:47:00 -0000 Hi list, when this release could go in FreeBSD ? I'm interested in this: >Fixed a fault in the AML parser if a memory allocation fails during the Op completion routine AcpiPsCompleteThisOp. Lin Ming. ACPICA BZ 492. actually it will be interesting for me to know how the process of adopting ACPICA works... I'll be grateful if someone can explain it briefly thank you Regards MGP >26 September 2008. Summary of changes for version 20080926: > >This release is available at www.acpica.org/downloads. > >1) ACPI CA Core Subsystem: > >Designed and implemented a mechanism to validate predefined ACPI methods and objects. This code validates the predefined ACPI objects (objects whose names start with underscore) that appear in the namespace, at the time they are evaluated. The argument count and the type of the returned object are validated against the ACPI specification. The purpose of this validation is to detect problems with the BIOS-implemented predefined ACPI objects before the results are returned to the ACPI-related drivers. Future enhancements may include actual repair of incorrect return objects where possible. Two new files are nspredef.c and acpredef.h. > >Fixed a fault in the AML parser if a memory allocation fails during the Op completion routine AcpiPsCompleteThisOp. Lin Ming. ACPICA BZ 492. > >Fixed an issue with implicit return compatibility. This change improves the implicit return mechanism to be more compatible with the MS interpreter. Lin Ming, ACPICA BZ 349. > >Implemented support for zero-length buffer-to-string conversions. Allow zero length strings during interpreter buffer-to-string conversions. For example, during the ToDecimalString and ToHexString operators, as well as implicit conversions. Fiodor Suietov, ACPICA BZ 585. > >Fixed two possible memory leaks in the error exit paths of AcpiUtUpdateObjectReference and AcpiUtWalkPackageTree. These functions are similar in that they use a stack of state objects in order to eliminate recursion. The stack must be fully unwound and deallocated if an error occurs. Lin Ming. ACPICA BZ 383. > >Removed the unused ACPI_BITREG_WAKE_ENABLE definition and entry in the global ACPI register table. This bit does not exist and is unused. Lin Ming, Bob Moore ACPICA BZ 442. > >Removed the obsolete version number in module headers. Removed the "$Revision" number that appeared in each module header. This version number was useful under SourceSafe and CVS, but has no meaning under git. It is not only incorrect, it could also be misleading. > >Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size. > > Previous Release: > Non-Debug Version: 79.7K Code, 16.4K Data, 96.1K Total > Debug Version: 153.7K Code, 48.2K Data, 201.9K Total > Current Release: > Non-Debug Version: 81.2K Code, 17.0K Data, 98.2K Total > Debug Version: 155.8K Code, 49.1K Data, 204.9K Total