From bugmaster at FreeBSD.org Mon Sep 1 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:07:06 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200809011106.m81B6oZN068337@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 19 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/124223 acpi [acpi] [patch] acpi_battery.c -- Notify user-defined c o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To 23 problems total. From lists at peter.de.com Mon Sep 1 13:28:26 2008 From: lists at peter.de.com (Oliver Peter) Date: Mon Sep 1 13:28:35 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] Message-ID: <20080901141216.72601dfb@dilbert.office.centralnic.com> Hi, For about 6 weeks I'm suffering an interrupt storm on my production machine which is running 7.0-RELEASE-p3/amd64. The kernel is flooding my syslog with the following messages[1]. A full dmesg can be found here[2]. As discribed in "Using and Debugging FreeBSD ACPI" I already tried to disable apic during boot time but that's a bad idea because it seems that the SATA2 onboard controller has to have apic loaded - please correct me if I'm wrong. /boot/loader.conf: hint.apic.0.disabled="1" Doesn't work for me. Btw. I think it's worth it to have a little note in that part of the documentation which says something about possible failures during the boot time. Thanks for any suggestions. Bye O. ========================== [1] /var/log/messages ========================== ... Jul 23 09:29:19 charlie kernel: interrupt storm detected on "irq22:"; throttling interrupt source Jul 23 09:29:50 charlie last message repeated 31 times Jul 23 09:31:51 charlie last message repeated 120 times Jul 23 09:41:52 charlie last message repeated 597 times Jul 23 09:51:52 charlie last message repeated 597 times Jul 23 10:01:53 charlie last message repeated 597 times Jul 23 10:11:52 charlie last message repeated 596 times Jul 23 10:21:53 charlie last message repeated 597 times Jul 23 10:31:52 charlie last message repeated 596 times Jul 23 10:41:53 charlie last message repeated 597 times Jul 23 10:51:53 charlie last message repeated 596 times Jul 23 11:01:53 charlie last message repeated 597 times Jul 23 11:11:53 charlie last message repeated 596 times ... Aug 14 14:00:01 charlie kernel: interrupt storm detected on "irq22:"; throttling interrupt source Aug 14 14:00:32 charlie last message repeated 31 times Aug 14 14:02:33 charlie last message repeated 120 times Aug 14 14:12:34 charlie last message repeated 597 times Aug 14 14:22:35 charlie last message repeated 598 times Aug 14 14:32:36 charlie last message repeated 597 times Aug 14 14:42:37 charlie last message repeated 597 times Aug 14 14:52:38 charlie last message repeated 598 times Aug 14 15:02:39 charlie last message repeated 597 times Aug 14 15:12:40 charlie last message repeated 597 times Aug 14 15:22:41 charlie last message repeated 598 times ... ========================== [2] dmesg ========================== Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p1 #4: Thu Jun 19 18:03:38 BST 2008 root@charlie.mouhaha.de:/usr/obj/usr/src/sys/CHARLIE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2899.98-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 2099699712 (2002 MB) avail memory = 2024751104 (1930 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jun 19 2008 18:02:12) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7df00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:b6:ce:92 re0: [FILTER] re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] orm0: at iomem 0xcd800-0xce7ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec hptrr: no controller detected. ZFS filesystem version 6 ZFS storage pool version 6 ad4: 476940MB at ata2-master UDMA33 ad6: 476940MB at ata3-master UDMA33 SMP: AP CPU #1 Launched! Trying to mount root from zfs:tank re0: link state changed to UP cryptosoft0: on motherboard -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "I like to con people. And I like to insult people. If you combine con & insult, you get consult!" -- Dogbert From miguel at anjos.strangled.net Mon Sep 1 21:13:45 2008 From: miguel at anjos.strangled.net (Miguel Lopes Santos Ramos) Date: Mon Sep 1 21:13:51 2008 Subject: Suspend/Resume on AMD64 In-Reply-To: <200808301838.m7UIc4hE018292@sana.init-main.com> Message-ID: <200809012113.m81LDK1R024104@satan.anjos.strangled.net> This is pretty scary... There's much more to be done than I thought. Well, I'm editing code without paying attention to consequences. It can't hurt anyone until it runs... I'm starting with the easyest part: adding the extra registers (r8-r15, cool!, I wish I had these back in my days of assembly programming). I am also taking a look at amd64/amd64/mpboot.S, which contains protected mode and 64-bit mode initialization, needed for wakeup. It is too early to need help. I'm still learning about AMD64 and refreshing my memory of control registers. I will contact you again in a week or so, if it's ok. Miguel > From takawata@init-main.com Sat Aug 30 20:10:23 2008 > > In message <200808301751.m7UHprcc023311@satan.anjos.strangled.net>, Miguel Lope > s Santos Ramos wrote: > > > >Hi, > > > >I'm running amd64 on my laptop since early 2005. > >Had a bunch of problems, ehci, radeon, etc, but most were fixed by someone sin > >ce then. > >One thing I still miss though is ACPI suspend/resume. > >Browsing through dev/acpica I found out that this feature set is simply disabl > >ed outside i386 > >(several #ifndef __i386__) and figured that maybe that's just because no one a > >ppeared to test it. > > The code is in i386/acpica/acpi_wakeup.c, i386/acpica/acpi_wakecode.S > > > >Well, I hereby volunteer to test this. > >I have already removed the ifndefs and achieved a machine hang when tried to s > >uspend. > > > >I have some experience with 80386 initialization (almost obsolete), > >I am a capable programmer (able to keep the indentation of an existing source > >file), > >and may be able to develop some new code if someone points me to the right > >documents at Intel or AMD. > >I am partially available on weekends. > > > >Will someone involved with suspend/resume on i386 help me on this? > > You called me? :-) > > >Would it be necessary to move to -CURRENT? > >Where should I start? > > Copy the code to amd64/acpica/ then try to run as it is. > In amd64, you have to preserve many registers than i386, so > the code should be more ABI aware. > http://2008.asiabsdcon.org/papers/P9A-paper.pdf > > To debug lowest part of resume code, you may want to use > BEEP debug. > > I wrote incomplete SMP suspend/resume code 3 months ago. > http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004879.html > > Indeed, I reserve 10GB partition to my primary laptop > to develop amd64 suspend/resume.But I don't even install it yet. > So if you implement it, I'm willing to test it :-P. From d.vashistha at gmail.com Tue Sep 2 06:32:06 2008 From: d.vashistha at gmail.com (Deepak Vashistha) Date: Tue Sep 2 06:32:13 2008 Subject: Power management in freebsd Message-ID: <5b3db66a0809012308t18faa687lc00257523e8e1c22@mail.gmail.com> Dear sir, I am using freebsd 7.0 and i want to enable powermanagement but for this configuration what setting i have to do please help me i have intel server board for PIII processor and bios is acpi/apm enabled. With Regards Deepak Vashistha From oberman at es.net Tue Sep 2 16:57:33 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Sep 2 16:57:39 2008 Subject: Power management in freebsd In-Reply-To: Your message of "Tue, 02 Sep 2008 11:38:59 +0530." <5b3db66a0809012308t18faa687lc00257523e8e1c22@mail.gmail.com> Message-ID: <20080902164650.344634500F@ptavv.es.net> > Date: Tue, 2 Sep 2008 11:38:59 +0530 > From: "Deepak Vashistha" > Sender: owner-freebsd-acpi@freebsd.org > > Dear sir, > I am using freebsd 7.0 and i want to enable powermanagement but for this > configuration what setting i have to do please help me i have intel server > board for PIII processor and bios is acpi/apm enabled. PIII has very limited power management and the ACPI implementations are often incomplete or simply broken. I would suggest using APM and not ACPI. (Note that APM and ACPI are mutually exclusive. You can't really run both at the same time although the APM emulation in FreeBSD makes it look a lot like both are running.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080902/1e3eb747/attachment.pgp From stevefranks at ieee.org Tue Sep 2 22:21:53 2008 From: stevefranks at ieee.org (Steve Franks) Date: Tue Sep 2 22:22:00 2008 Subject: Suspend/Resume on AMD64 In-Reply-To: <200809012113.m81LDK1R024104@satan.anjos.strangled.net> References: <200808301838.m7UIc4hE018292@sana.init-main.com> <200809012113.m81LDK1R024104@satan.anjos.strangled.net> Message-ID: <539c60b90809021459g65d9a1b7j40ae129c5ff9d562@mail.gmail.com> If you're looking for more volunteers, I've been highly disappointed for sometime in the lack of support for amd64, especially for suspend. I'm a reasonable C programmer as well, and I've got about 5 boxes deployed to test on. The one thing I don't have is oodles of time for learning new stuff, I'm afraid (little feet around the house these days...) It's somewhat suprising that our "sever-grade" os sticks with the lowest-common denominator for everything - don't we want terabytes of ram? I had enough icky experiences with linux a while back to make me stick with freebsd, so let's flush out the feature set, a bit. Steve On Mon, Sep 1, 2008 at 2:13 PM, Miguel Lopes Santos Ramos wrote: > > This is pretty scary... > There's much more to be done than I thought. > > Well, I'm editing code without paying attention to consequences. > It can't hurt anyone until it runs... > > I'm starting with the easyest part: adding the extra registers (r8-r15, cool!, I > wish I had these back in my days of assembly programming). > > I am also taking a look at amd64/amd64/mpboot.S, which contains protected mode > and 64-bit mode initialization, needed for wakeup. > > It is too early to need help. > I'm still learning about AMD64 and refreshing my memory of control registers. > > I will contact you again in a week or so, if it's ok. > > Miguel > >> From takawata@init-main.com Sat Aug 30 20:10:23 2008 >> >> In message <200808301751.m7UHprcc023311@satan.anjos.strangled.net>, Miguel Lope >> s Santos Ramos wrote: >> > >> >Hi, >> > >> >I'm running amd64 on my laptop since early 2005. >> >Had a bunch of problems, ehci, radeon, etc, but most were fixed by someone sin >> >ce then. >> >One thing I still miss though is ACPI suspend/resume. >> >Browsing through dev/acpica I found out that this feature set is simply disabl >> >ed outside i386 >> >(several #ifndef __i386__) and figured that maybe that's just because no one a >> >ppeared to test it. >> >> The code is in i386/acpica/acpi_wakeup.c, i386/acpica/acpi_wakecode.S >> >> >> >Well, I hereby volunteer to test this. >> >I have already removed the ifndefs and achieved a machine hang when tried to s >> >uspend. >> > >> >I have some experience with 80386 initialization (almost obsolete), >> >I am a capable programmer (able to keep the indentation of an existing source >> >file), >> >and may be able to develop some new code if someone points me to the right >> >documents at Intel or AMD. >> >I am partially available on weekends. >> > >> >Will someone involved with suspend/resume on i386 help me on this? >> >> You called me? :-) >> >> >Would it be necessary to move to -CURRENT? >> >Where should I start? >> >> Copy the code to amd64/acpica/ then try to run as it is. >> In amd64, you have to preserve many registers than i386, so >> the code should be more ABI aware. >> http://2008.asiabsdcon.org/papers/P9A-paper.pdf >> >> To debug lowest part of resume code, you may want to use >> BEEP debug. >> >> I wrote incomplete SMP suspend/resume code 3 months ago. >> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004879.html >> >> Indeed, I reserve 10GB partition to my primary laptop >> to develop amd64 suspend/resume.But I don't even install it yet. >> So if you implement it, I'm willing to test it :-P. > _______________________________________________ > 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 niktychina at gmail.com Wed Sep 3 18:32:50 2008 From: niktychina at gmail.com (=?KOI8-R?B?7snLz8zByiD02d7JzsE=?=) Date: Wed Sep 3 18:32:57 2008 Subject: ACER Aspire 5520's fixed .asl In-Reply-To: References: Message-ID: Hi all, i fixed .asl of my acer laptop yesterday (by analogy with 5720's from http://acpi.sf.net), so there aren't any errors and warnings now. You can find it here: http://slil.ru/26113392 Today: # iasl asp5520g-ok-3.asl Intel ACPI Component Architecture ASL Optimizing Compiler version 20070320 [Feb 24 2008] Copyright (C) 2000 - 2007 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: asp5520g-ok-3.asl - 7141 lines, 242150 bytes, 2974 keywords AML Output: /tmp/acpidump.aml - 24543 bytes 878 named objects 2096 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 731 Optimizations I copied /tmp/acpidump.aml to /boot/DSDT.aml and added acpi_dsdt_load="YES" and acpi_dsdt_name="/boot/DSDT.aml" to /boot/loader.conf. But... i still have console errors and acpiconf doesn't see battery :( Nothing has changed :( So, help pls, i was so glad yesterday :) From gahr at FreeBSD.org Fri Sep 5 16:42:31 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Fri Sep 5 16:42:38 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <48C14091.4060309@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 POKE! Anybody interested in reviewing it? - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjBQI8ACgkQwMJqmJVx946CrQCfY7I1sTPwoPte89cP5zXg5j8S YNUAnjO41f8uzOPFDRR9XAvcEiHcB9ID =ef6A -----END PGP SIGNATURE----- From gahr at FreeBSD.org Fri Sep 5 16:50:05 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Fri Sep 5 16:50:11 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809051650.m85Go3fu097107@freefall.freebsd.org> The following reply was made to PR kern/124223; it has been noted by GNATS. From: Pietro Cerutti To: bug-followup@FreeBSD.org, gahr@FreeBSD.org, freebsd-acpi@freebsd.org Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Fri, 05 Sep 2008 16:22:09 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 POKE! Anybody interested in reviewing it? - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjBQI8ACgkQwMJqmJVx946CrQCfY7I1sTPwoPte89cP5zXg5j8S YNUAnjO41f8uzOPFDRR9XAvcEiHcB9ID =ef6A -----END PGP SIGNATURE----- From nate at root.org Fri Sep 5 17:10:43 2008 From: nate at root.org (Nate Lawson) Date: Fri Sep 5 17:10:49 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C14091.4060309@FreeBSD.org> References: <48C14091.4060309@FreeBSD.org> Message-ID: <48C16810.2030003@root.org> There are a few problems with your approach. Critical status is already reported with a flag when usermode polls for the battery status: > if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > sc->flags |= ACPI_BATT_STAT_CRITICAL; > device_printf(dev, "critically low charge!\n"); > } > } Since usermode utilities already poll, they can handle that flag or implement their own notion of critical battery level. Why introduce a new kernel thread to do that same polling? Don't common battery status tools that poll (say, xbatt) have their own way to set a critical level? -Nate Pietro Cerutti wrote: > POKE! > > Anybody interested in reviewing it? -- Nate From nate at root.org Fri Sep 5 17:30:05 2008 From: nate at root.org (Nate Lawson) Date: Fri Sep 5 17:30:35 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809051730.m85HU5q6000155@freefall.freebsd.org> The following reply was made to PR kern/124223; it has been noted by GNATS. From: Nate Lawson To: Pietro Cerutti Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Fri, 05 Sep 2008 10:10:40 -0700 There are a few problems with your approach. Critical status is already reported with a flag when usermode polls for the battery status: > if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > sc->flags |= ACPI_BATT_STAT_CRITICAL; > device_printf(dev, "critically low charge!\n"); > } > } Since usermode utilities already poll, they can handle that flag or implement their own notion of critical battery level. Why introduce a new kernel thread to do that same polling? Don't common battery status tools that poll (say, xbatt) have their own way to set a critical level? -Nate Pietro Cerutti wrote: > POKE! > > Anybody interested in reviewing it? -- Nate From bugmaster at FreeBSD.org Mon Sep 8 02:22:16 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:22:22 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200809080222.m882MF0K006584@freefall.freebsd.org> 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/124223 acpi [acpi] [patch] acpi_battery.c -- Notify user-defined c 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 42 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From jhb at freebsd.org Mon Sep 8 20:12:04 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 8 20:12:10 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <20080901141216.72601dfb@dilbert.office.centralnic.com> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> Message-ID: <200809081108.50135.jhb@freebsd.org> On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > Hi, > > For about 6 weeks I'm suffering an interrupt storm on my production > machine which is running 7.0-RELEASE-p3/amd64. > > The kernel is flooding my syslog with the following messages[1]. > A full dmesg can be found here[2]. > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > to disable apic during boot time but that's a bad idea because it > seems that the SATA2 onboard controller has to have apic loaded - > please correct me if I'm wrong. > > /boot/loader.conf: > hint.apic.0.disabled="1" > > Doesn't work for me. > > Btw. I think it's worth it to have a little note in that part of > the documentation which says something about possible failures > during the boot time. > > Thanks for any suggestions. There are two possible causes of an interrupt storm: 1) some device is actually using IRQ 22 but FreeBSD thinks it is using something else. This doesn't happen very often as it is generally a bug in the BIOS and one of the tables it generates. This used to happen more often in older versions of FreeBSD that had bugs or limitations in the code that figured out which IRQ PCI devices used. 2) There is a bug in the driver for one of the devices on IRQ 22. In this case the only device you have on IRQ is atapci0, so it may be a bug in the ata(4) driver, possibly. You could check to see if the interrupt handler for the Linux driver for your chipset has extra logic (currently ata(4) doesn't have any chipset-specific logic for interrupt handlers AFAIK). Also, you could try examining the interrupt status register of your controller when you are getting storms to see if there is a condition set that isn't being cleared by ata's interrupt handler. -- John Baldwin From gahr at FreeBSD.org Mon Sep 8 21:44:00 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Mon Sep 8 21:44:07 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C16810.2030003@root.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> Message-ID: <48C59C98.5020408@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | There are a few problems with your approach. | | Critical status is already reported with a flag when usermode polls for | the battery status: |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> device_printf(dev, "critically low charge!\n"); |> } |> } I agree. Critical level is already checked for in the cmbat module. However, reporting is not done in a "standardized" way. My patch would just like to add notification through devd. | Since usermode utilities already poll, they can handle that flag or | implement their own notion of critical battery level. Why introduce a | new kernel thread to do that same polling? Because you can't configure the notion of "critical level" via cmbat. | | Don't common battery status tools that poll (say, xbatt) have their own | way to set a critical level? xbatt uses APM and ioctl to get the status of the battery. I agree that userlevel utilities can e.g., retrieve the remaining percent and set the critical level arbitrarily, but I anyway think that a configurable level to be seen as critical by the OS could be a useful addition. I'm open to discussions about the best way to implement it (cmbat, battery, ...?), if we get to an agreement that this could be a useful feature :) Otherwise feel free to close the PR, as I can accept your arguments. | | -Nate | | Pietro Cerutti wrote: |> POKE! |> |> Anybody interested in reviewing it? | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFnJcACgkQwMJqmJVx946mtgCgivQVqG6nrctsffXFdm5HRQfX 1OUAoL9TXYwwiNfHvnUclKAhVzWcnw9S =3q5J -----END PGP SIGNATURE----- From gahr at FreeBSD.org Mon Sep 8 21:50:03 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Mon Sep 8 21:50:10 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809082150.m88Lo3Ma050947@freefall.freebsd.org> The following reply was made to PR kern/124223; it has been noted by GNATS. From: Pietro Cerutti To: Nate Lawson Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Mon, 08 Sep 2008 23:43:52 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | There are a few problems with your approach. | | Critical status is already reported with a flag when usermode polls for | the battery status: |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> device_printf(dev, "critically low charge!\n"); |> } |> } I agree. Critical level is already checked for in the cmbat module. However, reporting is not done in a "standardized" way. My patch would just like to add notification through devd. | Since usermode utilities already poll, they can handle that flag or | implement their own notion of critical battery level. Why introduce a | new kernel thread to do that same polling? Because you can't configure the notion of "critical level" via cmbat. | | Don't common battery status tools that poll (say, xbatt) have their own | way to set a critical level? xbatt uses APM and ioctl to get the status of the battery. I agree that userlevel utilities can e.g., retrieve the remaining percent and set the critical level arbitrarily, but I anyway think that a configurable level to be seen as critical by the OS could be a useful addition. I'm open to discussions about the best way to implement it (cmbat, battery, ...?), if we get to an agreement that this could be a useful feature :) Otherwise feel free to close the PR, as I can accept your arguments. | | -Nate | | Pietro Cerutti wrote: |> POKE! |> |> Anybody interested in reviewing it? | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFnJcACgkQwMJqmJVx946mtgCgivQVqG6nrctsffXFdm5HRQfX 1OUAoL9TXYwwiNfHvnUclKAhVzWcnw9S =3q5J -----END PGP SIGNATURE----- From nate at root.org Mon Sep 8 22:04:05 2008 From: nate at root.org (Nate Lawson) Date: Mon Sep 8 22:04:12 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C59C98.5020408@FreeBSD.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> Message-ID: <48C5A152.9020505@root.org> Pietro Cerutti wrote: > Nate Lawson wrote: > | There are a few problems with your approach. > | > | Critical status is already reported with a flag when usermode polls for > | the battery status: > |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> device_printf(dev, "critically low charge!\n"); > |> } > |> } > > I agree. Critical level is already checked for in the cmbat module. > However, reporting is not done in a "standardized" way. My patch would > just like to add notification through devd. But it doesn't just add notification through devd. It adds a thread, that separately polls for battery state and sends a notify through devd. If the user is running any battery app, there's a double poll for the same info. I subscribe to the design approach that where it makes sense to do something in usermode, don't do it in kernel mode. In this case, the IO interface is poll-only, and any user app that is running can set its own policy for how to deal with the information it gets from polling. > I agree that userlevel utilities can e.g., retrieve the remaining > percent and set the critical level arbitrarily, but I anyway think that > a configurable level to be seen as critical by the OS could be a useful > addition. > > I'm open to discussions about the best way to implement it (cmbat, > battery, ...?), if we get to an agreement that this could be a useful > feature :) Otherwise feel free to close the PR, as I can accept your > arguments. I think it would be better to work with the third-party apps to support configurable levels. In xbatt: /* If battery life is short, ring a bell */ if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) { ... and ... /* set gage color */ if (displayType == Color) { if (life < 3) { gage_color = "red"; } else if (life < 5) { gage_color = "yellow"; } } These thresholds could easily be a command-line var or X resource. Let's keep this in usermode, where policy belongs. -- Nate From nate at root.org Mon Sep 8 22:10:07 2008 From: nate at root.org (Nate Lawson) Date: Mon Sep 8 22:10:14 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809082210.m88MA7DZ051637@freefall.freebsd.org> The following reply was made to PR kern/124223; it has been noted by GNATS. From: Nate Lawson To: Pietro Cerutti Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Mon, 08 Sep 2008 15:04:02 -0700 Pietro Cerutti wrote: > Nate Lawson wrote: > | There are a few problems with your approach. > | > | Critical status is already reported with a flag when usermode polls for > | the battery status: > |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> device_printf(dev, "critically low charge!\n"); > |> } > |> } > > I agree. Critical level is already checked for in the cmbat module. > However, reporting is not done in a "standardized" way. My patch would > just like to add notification through devd. But it doesn't just add notification through devd. It adds a thread, that separately polls for battery state and sends a notify through devd. If the user is running any battery app, there's a double poll for the same info. I subscribe to the design approach that where it makes sense to do something in usermode, don't do it in kernel mode. In this case, the IO interface is poll-only, and any user app that is running can set its own policy for how to deal with the information it gets from polling. > I agree that userlevel utilities can e.g., retrieve the remaining > percent and set the critical level arbitrarily, but I anyway think that > a configurable level to be seen as critical by the OS could be a useful > addition. > > I'm open to discussions about the best way to implement it (cmbat, > battery, ...?), if we get to an agreement that this could be a useful > feature :) Otherwise feel free to close the PR, as I can accept your > arguments. I think it would be better to work with the third-party apps to support configurable levels. In xbatt: /* If battery life is short, ring a bell */ if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) { ... and ... /* set gage color */ if (displayType == Color) { if (life < 3) { gage_color = "red"; } else if (life < 5) { gage_color = "yellow"; } } These thresholds could easily be a command-line var or X resource. Let's keep this in usermode, where policy belongs. -- Nate From gahr at FreeBSD.org Mon Sep 8 22:14:23 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Mon Sep 8 22:14:29 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C5A152.9020505@root.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> Message-ID: <48C5A3B6.2070807@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | There are a few problems with your approach. |> | |> | Critical status is already reported with a flag when usermode polls for |> | the battery status: |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> device_printf(dev, "critically low charge!\n"); |> |> } |> |> } |> |> I agree. Critical level is already checked for in the cmbat module. |> However, reporting is not done in a "standardized" way. My patch would |> just like to add notification through devd. | | But it doesn't just add notification through devd. It adds a thread, | that separately polls for battery state and sends a notify through devd. | If the user is running any battery app, there's a double poll for the | same info. | | I subscribe to the design approach that where it makes sense to do | something in usermode, don't do it in kernel mode. In this case, the IO | interface is poll-only, and any user app that is running can set its own | policy for how to deal with the information it gets from polling. [snip xbatt-related stuff] | Let's keep this in usermode, where policy belongs. That's fine. Thanks for reviewing that! Best, - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFo7UACgkQwMJqmJVx945TJQCfTRuG0ZiMSfyIaw0rb/5C1cXY E4oAoJdERo/AA7KwGRtYnVEQeUoPo9Az =UAwz -----END PGP SIGNATURE----- From gahr at FreeBSD.org Mon Sep 8 22:15:01 2008 From: gahr at FreeBSD.org (gahr@FreeBSD.org) Date: Mon Sep 8 22:15:07 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809082215.m88MF0AS053269@freefall.freebsd.org> Synopsis: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) State-Changed-From-To: open->closed State-Changed-By: gahr State-Changed-When: Mon Sep 8 22:15:00 UTC 2008 State-Changed-Why: Policy belongs to usermode. http://www.freebsd.org/cgi/query-pr.cgi?pr=124223 From gahr at FreeBSD.org Mon Sep 8 22:20:05 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Mon Sep 8 22:20:11 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <200809082220.m88MK4TA053459@freefall.freebsd.org> The following reply was made to PR kern/124223; it has been noted by GNATS. From: Pietro Cerutti To: Nate Lawson Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Tue, 09 Sep 2008 00:14:14 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | There are a few problems with your approach. |> | |> | Critical status is already reported with a flag when usermode polls for |> | the battery status: |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> device_printf(dev, "critically low charge!\n"); |> |> } |> |> } |> |> I agree. Critical level is already checked for in the cmbat module. |> However, reporting is not done in a "standardized" way. My patch would |> just like to add notification through devd. | | But it doesn't just add notification through devd. It adds a thread, | that separately polls for battery state and sends a notify through devd. | If the user is running any battery app, there's a double poll for the | same info. | | I subscribe to the design approach that where it makes sense to do | something in usermode, don't do it in kernel mode. In this case, the IO | interface is poll-only, and any user app that is running can set its own | policy for how to deal with the information it gets from polling. [snip xbatt-related stuff] | Let's keep this in usermode, where policy belongs. That's fine. Thanks for reviewing that! Best, - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFo7UACgkQwMJqmJVx945TJQCfTRuG0ZiMSfyIaw0rb/5C1cXY E4oAoJdERo/AA7KwGRtYnVEQeUoPo9Az =UAwz -----END PGP SIGNATURE----- From nate at root.org Mon Sep 8 22:32:02 2008 From: nate at root.org (Nate Lawson) Date: Mon Sep 8 22:32:08 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C5A3B6.2070807@FreeBSD.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> <48C5A3B6.2070807@FreeBSD.org> Message-ID: <48C5A7E0.3010308@root.org> Pietro Cerutti wrote: > Nate Lawson wrote: > | Pietro Cerutti wrote: > |> Nate Lawson wrote: > |> | There are a few problems with your approach. > |> | > |> | Critical status is already reported with a flag when usermode polls > for > |> | the battery status: > |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> |> device_printf(dev, "critically low charge!\n"); > |> |> } > |> |> } > |> > |> I agree. Critical level is already checked for in the cmbat module. > |> However, reporting is not done in a "standardized" way. My patch would > |> just like to add notification through devd. > | > | But it doesn't just add notification through devd. It adds a thread, > | that separately polls for battery state and sends a notify through devd. > | If the user is running any battery app, there's a double poll for the > | same info. > | > | I subscribe to the design approach that where it makes sense to do > | something in usermode, don't do it in kernel mode. In this case, the IO > | interface is poll-only, and any user app that is running can set its own > | policy for how to deal with the information it gets from polling. > > [snip xbatt-related stuff] > > | Let's keep this in usermode, where policy belongs. > > That's fine. Thanks for reviewing that! Thanks for helping with FreeBSD. Hope you'll work on other stuff in the future. -- Nate From gahr at FreeBSD.org Mon Sep 8 22:34:04 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Mon Sep 8 22:34:11 2008 Subject: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) In-Reply-To: <48C5A7E0.3010308@root.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> <48C5A3B6.2070807@FreeBSD.org> <48C5A7E0.3010308@root.org> Message-ID: <48C5A852.4040909@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | Pietro Cerutti wrote: |> |> Nate Lawson wrote: |> |> | There are a few problems with your approach. |> |> | |> |> | Critical status is already reported with a flag when usermode polls |> for |> |> | the battery status: |> |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> |> device_printf(dev, "critically low charge!\n"); |> |> |> } |> |> |> } |> |> |> |> I agree. Critical level is already checked for in the cmbat module. |> |> However, reporting is not done in a "standardized" way. My patch would |> |> just like to add notification through devd. |> | |> | But it doesn't just add notification through devd. It adds a thread, |> | that separately polls for battery state and sends a notify through devd. |> | If the user is running any battery app, there's a double poll for the |> | same info. |> | |> | I subscribe to the design approach that where it makes sense to do |> | something in usermode, don't do it in kernel mode. In this case, the IO |> | interface is poll-only, and any user app that is running can set its own |> | policy for how to deal with the information it gets from polling. |> |> [snip xbatt-related stuff] |> |> | Let's keep this in usermode, where policy belongs. |> |> That's fine. Thanks for reviewing that! | | Thanks for helping with FreeBSD. Hope you'll work on other stuff in the | future. Stay assured :) - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFqFEACgkQwMJqmJVx946SqgCgrmDAjzwZcRURJmspEu5178xt 4aAAoNi+PRH6adhJf3QpllLGXwfPEDzD =y/OG -----END PGP SIGNATURE----- From lists at peter.de.com Mon Sep 8 23:08:20 2008 From: lists at peter.de.com (Oliver Peter) Date: Mon Sep 8 23:08:25 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <200809081108.50135.jhb@freebsd.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> Message-ID: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> Hi John, Thanks for your reply. On Mon, 8 Sep 2008 11:08:49 -0400 John Baldwin wrote: > On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > > Hi, > > > > For about 6 weeks I'm suffering an interrupt storm on my production > > machine which is running 7.0-RELEASE-p3/amd64. > > > > The kernel is flooding my syslog with the following messages[1]. > > A full dmesg can be found here[2]. > > > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > > to disable apic during boot time but that's a bad idea because it > > seems that the SATA2 onboard controller has to have apic loaded - > > please correct me if I'm wrong. > > > > /boot/loader.conf: > > hint.apic.0.disabled="1" > > > > Doesn't work for me. > > > > Btw. I think it's worth it to have a little note in that part of > > the documentation which says something about possible failures > > during the boot time. > > > > Thanks for any suggestions. > > There are two possible causes of an interrupt storm: 1) some device > is actually using IRQ 22 but FreeBSD thinks it is using something > else. This doesn't happen very often as it is generally a bug in the > BIOS and one of the tables it generates. This used to happen more > often in older versions of FreeBSD that had bugs or limitations in > the code that figured out which IRQ PCI devices used. How can I find out exactly which device is using IRQ 22? Maybe I can disable it - i.e. USB is not needed at all. > 2) There is a > bug in the driver for one of the devices on IRQ 22. In this case the > only device you have on IRQ is atapci0, so it may be a bug in the > ata(4) driver, possibly. You could check to see if the interrupt > handler for the Linux driver for your chipset has extra logic > (currently ata(4) doesn't have any chipset-specific logic for > interrupt handlers AFAIK). Also, you could try examining the > interrupt status register of your controller when you are getting > storms to see if there is a condition set that isn't being cleared by > ata's interrupt handler. ... of course I could do that - but could you please be so kind and explain how to do that? :-) Cheers, O. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From peterjeremy at optushome.com.au Tue Sep 9 07:54:22 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Sep 9 07:54:29 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <200809081108.50135.jhb@freebsd.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> Message-ID: <20080909075416.GF15376@server.vk2pj.dyndns.org> On 2008-Sep-08 11:08:49 -0400, John Baldwin wrote: >There are two possible causes of an interrupt storm: There is a third possible option (I have cards that do this): The device is generating interrupts without being told to do so. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080909/662800b8/attachment.pgp From jhb at freebsd.org Tue Sep 9 21:04:32 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 9 21:04:38 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> Message-ID: <200809091424.16302.jhb@freebsd.org> On Monday 08 September 2008 07:08:05 pm Oliver Peter wrote: > Hi John, > > Thanks for your reply. > > On Mon, 8 Sep 2008 11:08:49 -0400 > John Baldwin wrote: > > > On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > > > Hi, > > > > > > For about 6 weeks I'm suffering an interrupt storm on my production > > > machine which is running 7.0-RELEASE-p3/amd64. > > > > > > The kernel is flooding my syslog with the following messages[1]. > > > A full dmesg can be found here[2]. > > > > > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > > > to disable apic during boot time but that's a bad idea because it > > > seems that the SATA2 onboard controller has to have apic loaded - > > > please correct me if I'm wrong. > > > > > > /boot/loader.conf: > > > hint.apic.0.disabled="1" > > > > > > Doesn't work for me. > > > > > > Btw. I think it's worth it to have a little note in that part of > > > the documentation which says something about possible failures > > > during the boot time. > > > > > > Thanks for any suggestions. > > > > There are two possible causes of an interrupt storm: 1) some device > > is actually using IRQ 22 but FreeBSD thinks it is using something > > else. This doesn't happen very often as it is generally a bug in the > > BIOS and one of the tables it generates. This used to happen more > > often in older versions of FreeBSD that had bugs or limitations in > > the code that figured out which IRQ PCI devices used. > > How can I find out exactly which device is using IRQ 22? > Maybe I can disable it - i.e. USB is not needed at all. > > > 2) There is a > > bug in the driver for one of the devices on IRQ 22. In this case the > > only device you have on IRQ is atapci0, so it may be a bug in the > > ata(4) driver, possibly. You could check to see if the interrupt > > handler for the Linux driver for your chipset has extra logic > > (currently ata(4) doesn't have any chipset-specific logic for > > interrupt handlers AFAIK). Also, you could try examining the > > interrupt status register of your controller when you are getting > > storms to see if there is a condition set that isn't being cleared by > > ata's interrupt handler. > > ... 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. -- John Baldwin From dominique.goncalves at gmail.com Thu Sep 11 15:01:47 2008 From: dominique.goncalves at gmail.com (Dominique Goncalves) Date: Thu Sep 11 15:01:57 2008 Subject: HDD USB still on after computer shutdown Message-ID: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> Hi, I use FreeBSD 6.3-STABLE and an HDD USB (Maxtor, external PSU, 500GB). When I shutdown my computer (shutdown -p now ) the HDD USB is still on. In Windows XP it works, the HDD USB is off. I also searched in BIOS about an option to disable power for USB but wihout luck. Is there a way to resolve this issue? Let me know if you need more information. Thanks in advance, Regards %dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-STABLE #0: Thu May 29 20:17:28 CEST 2008 root@lost:/usr/obj/usr/src/sys/LOST Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2209.90-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 real memory = 805240832 (767 MB) avail memory = 774422528 (738 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (May 29 2008 20:17:09) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 device_attach: acpi_hpet0 attach returned 12 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered umass0: Maxtor Basics Desktop, rev 2.00/1.22, addr 2 pcib1: at device 4.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xcc00-0xcc3f irq 16 at device 5.0 on pci1 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:a0:24:f0:fc:71 fwohci0: mem 0xfd8ff000-0xfd8ff7ff,0xfd8f8000-0xfd8fbfff irq 19 at device 9.0 on pci1 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0a:e6:ff:69:86:6e fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:0a:69:86:6e fwe0: Ethernet address: 02:00:0a:69:86:6e fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcm0: mem 0xfe028000-0xfe02bfff irq 23 at device 5.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xfe02d000-0xfe02dfff irq 20 at device 8.0 on pci0 ata2: on atapci1 ata3: on atapci1 pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 mskc0: port 0xac00-0xacff mem 0xfdcfc000-0xfdcfffff irq 16 at device 0.0 on pci3 msk0: on mskc0 msk0: Ethernet address: 00:19:21:47:fc:89 miibus1: on msk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FAST] pcib4: at device 12.0 on pci0 pci4: on pcib4 pci0: at device 13.0 (no driver attached) acpi_tz0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 device_attach: acpi_hpet0 attach returned 12 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/20.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. umass1: vendor 0x058f USB Reader, rev 1.10/1.00, addr 3 Timecounter "TSC" frequency 2209902318 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: DVDR at ata0-master UDMA66 ad4: 238475MB at ata2-master SATA300 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim1 bus 1 target 0 lun 1 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim1 bus 1 target 0 lun 2 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present da4 at umass-sim1 bus 1 target 0 lun 3 da4: Removable Direct Access SCSI-0 device da4: 1.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s3a %sysctl hw.acpi 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: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 40,0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 122,0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 124,0C hw.acpi.thermal.tz0._ACx: 122,0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From amistry at am-productions.biz Fri Sep 12 13:50:19 2008 From: amistry at am-productions.biz (Anish Mistry) Date: Fri Sep 12 13:50:25 2008 Subject: HDD USB still on after computer shutdown In-Reply-To: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> References: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> Message-ID: <200809120937.39041.amistry@am-productions.biz> On Thursday 11 September 2008, Dominique Goncalves wrote: > Hi, > > I use FreeBSD 6.3-STABLE and an HDD USB (Maxtor, external PSU, > 500GB). When I shutdown my computer (shutdown -p now ) the HDD USB > is still on. In Windows XP it works, the HDD USB is off. > > I also searched in BIOS about an option to disable power for USB > but wihout luck. > > Is there a way to resolve this issue? > > Let me know if you need more information. You may need to send the suspend command to the device. http://freebsd.monkey.org/freebsd-usb/200803/msg00013.html -- Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080912/7fd9ebfa/attachment.pgp From bruce at cran.org.uk Fri Sep 12 23:29:07 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Sep 12 23:29:13 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <200807231116.02389.jhb@freebsd.org> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> <200807231116.02389.jhb@freebsd.org> Message-ID: <20080913002850.26f322ab@tau.draftnet> On Wed, 23 Jul 2008 11:16:02 -0400 John Baldwin wrote: > I've committed the patch. However, I think this actually points out > a slightly bigger issue in that the HPET timer is probably > piggybacking on the ichsmb0 device's BAR, and they really should both > be able to attach somehow. > > A way to fix that would be to make the HPET device actually borrow > the PCI device's resource instead of allocating its own perhaps. I > think the HPET ACPI device and the table tell us the PCI deviec the > HPET lives in. > I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop and hit this problem too. I noticed the patch was committed to HEAD - are there any plans to MFC it for 7.1? -- Bruce Cran From bugmaster at FreeBSD.org Mon Sep 15 15:18:43 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:19:00 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200809151518.m8FFIgEf018779@freefall.freebsd.org> 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 jhb at freebsd.org Mon Sep 15 20:49:46 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 20:50:00 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080913002850.26f322ab@tau.draftnet> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807231116.02389.jhb@freebsd.org> <20080913002850.26f322ab@tau.draftnet> Message-ID: <200809151548.33070.jhb@freebsd.org> On Friday 12 September 2008 07:28:50 pm Bruce Cran wrote: > On Wed, 23 Jul 2008 11:16:02 -0400 > John Baldwin wrote: > > I've committed the patch. However, I think this actually points out > > a slightly bigger issue in that the HPET timer is probably > > piggybacking on the ichsmb0 device's BAR, and they really should both > > be able to attach somehow. > > > > A way to fix that would be to make the HPET device actually borrow > > the PCI device's resource instead of allocating its own perhaps. I > > think the HPET ACPI device and the table tell us the PCI deviec the > > HPET lives in. > > > > I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop > and hit this problem too. I noticed the patch was committed to HEAD - > are there any plans to MFC it for 7.1? I will MFC it. -- John Baldwin From yerenkow at uct.ua Wed Sep 17 10:01:13 2008 From: yerenkow at uct.ua (A.Y.) Date: Wed Sep 17 10:01:20 2008 Subject: AsusEEE ACPI Message-ID: <48D0CEA9.2040205@uct.ua> Hello guys! I've AsusEEE 900 and freebsd-7 stable; I have acpi_asus loaded and my Fn buttons works ok. However, If few times kldunload and kldload acpi_asus.ko then only first Fn-stroke is handled (I've experimented on brightness), after that I had hung once; and in few more tests show that Fn buttons ignored. Could anyone look into it in free time? Or maybe anyone could gave me some info, link, or else. Anyway thanks! From Juergen.Dankoweit at T-Online.de Wed Sep 17 19:53:01 2008 From: Juergen.Dankoweit at T-Online.de (Juergen Dankoweit) Date: Wed Sep 17 19:53:08 2008 Subject: Thinkap T43 suspend/resume only once Message-ID: <1221680202.1720.10.camel@t43.juergendankoweit.net> Hello to the list. On my Thinkpad T43 every component works great with FreeBSD 7.0 and 7.1 PRERELEASE. 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 Where is the problem? If this is the wrong list, please tell me. Many thanks for your answers. Best regards J.D. Here the configuration files: /boot/loader.conf ---------------- # fuer T43 acpi_ibm_load="YES" # Sound-Modul laden snd_ich_load="YES" # Bluetooth ng_ubt_load="YES" # ATi-Radeon-Module fuer X300 radeon_load="YES" # fuer Mono kern.ipc.semmni=40 kern.ipc.semmns=300 # fuer gamin kern.maxfiles="25000" /etc/sysctl.conf ---------------- # ACPI fuer Thinkpad T43 # hw.acpi.reset_video=1 hw.acpi.lid_switch_state=S3 hw.acpi.sleep_button_state=S3 hw.acpi.power_button_state=S5 hw.acpi.sleep_delay=3 hw.acpi.verbose=1 dev.acpi_ibm.0.events=1 hw.syscons.sc_no_suspend_vtswitch=0 /etc/devd.conf (the relevant entry): ------------------------------------ # Suspend fuer IBM Thinkpad T43 notify 10 { match "system" "ACPI"; match "subsystem" "IBM"; match "notify" "0x04"; action "logger -t Fn+F4 && /etc/rc.suspend"; }; uname -a says: -------------- FreeBSD t43.juergendankoweit.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Sep 14 09:24:44 CEST 2008 juergen@t43.juergendankoweit.net:/usr/obj/usr/src/sys/GENERIC i386 From bugmaster at FreeBSD.org Mon Sep 22 11:06:48 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:06:53 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200809221106.m8MB6l4Q015267@freefall.freebsd.org> 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 lists at peter.de.com Mon Sep 22 15:29:12 2008 From: lists at peter.de.com (Oliver Peter) Date: Mon Sep 22 15:29:15 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <200809091424.16302.jhb@freebsd.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> <200809091424.16302.jhb@freebsd.org> Message-ID: <20080922150952.GA37948@nemesis.frida.mouhaha.de> 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 numardbsd at gmail.com Mon Sep 22 15:47:28 2008 From: numardbsd at gmail.com (Norberto Meijome) Date: Mon Sep 22 15:47:31 2008 Subject: Thinkap T43 suspend/resume only once In-Reply-To: <1221680202.1720.10.camel@t43.juergendankoweit.net> References: <1221680202.1720.10.camel@t43.juergendankoweit.net> Message-ID: <20080923011441.17751f9a@ayiin> 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 Juergen.Dankoweit at t-online.de Mon Sep 22 16:17:55 2008 From: Juergen.Dankoweit at t-online.de (=?ISO-8859-1?Q?J=FCrgen?= Dankoweit) Date: Mon Sep 22 16:17:57 2008 Subject: Thinkap T43 suspend/resume only once In-Reply-To: <20080923011441.17751f9a@ayiin> References: <1221680202.1720.10.camel@t43.juergendankoweit.net> <20080923011441.17751f9a@ayiin> Message-ID: <1222100237.1251.7.camel@t43.juergendankoweit.net> 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 jhb at freebsd.org Mon Sep 22 21:09:25 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 22 21:09:27 2008 Subject: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] In-Reply-To: <20080922150952.GA37948@nemesis.frida.mouhaha.de> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809091424.16302.jhb@freebsd.org> <20080922150952.GA37948@nemesis.frida.mouhaha.de> Message-ID: <200809221637.33168.jhb@freebsd.org> 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 gavin at FreeBSD.org Tue Sep 23 13:10:42 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Sep 23 13:10:51 2008 Subject: Writing a driver: how do I get resources? Message-ID: <1222173505.80882.15.camel@buffy.york.ac.uk> 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 jhb at freebsd.org Tue Sep 23 15:23:50 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 23 15:23:52 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <1222173505.80882.15.camel@buffy.york.ac.uk> References: <1222173505.80882.15.camel@buffy.york.ac.uk> Message-ID: <200809231037.00392.jhb@freebsd.org> 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 gavin at FreeBSD.org Tue Sep 23 17:21:26 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Sep 23 17:21:30 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <200809231037.00392.jhb@freebsd.org> References: <1222173505.80882.15.camel@buffy.york.ac.uk> <200809231037.00392.jhb@freebsd.org> Message-ID: <1222190482.80882.28.camel@buffy.york.ac.uk> 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 jhb at freebsd.org Tue Sep 23 19:12:16 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 23 19:12:18 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <1222190482.80882.28.camel@buffy.york.ac.uk> References: <1222173505.80882.15.camel@buffy.york.ac.uk> <200809231037.00392.jhb@freebsd.org> <1222190482.80882.28.camel@buffy.york.ac.uk> Message-ID: <200809231412.50418.jhb@freebsd.org> 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 nate at root.org Tue Sep 23 19:47:36 2008 From: nate at root.org (Nate Lawson) Date: Tue Sep 23 19:47:38 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <1222173505.80882.15.camel@buffy.york.ac.uk> References: <1222173505.80882.15.camel@buffy.york.ac.uk> Message-ID: <48D93006.7050400@root.org> 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 alex.wilkinson at dsto.defence.gov.au Wed Sep 24 03:58:52 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed Sep 24 03:58:55 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <48D93006.7050400@root.org> References: <1222173505.80882.15.camel@buffy.york.ac.uk> <48D93006.7050400@root.org> Message-ID: <20080924033538.GE9790@stlux503.dsto.defence.gov.au> 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 nate at root.org Wed Sep 24 04:44:12 2008 From: nate at root.org (Nate Lawson) Date: Wed Sep 24 04:44:15 2008 Subject: Writing a driver: how do I get resources? In-Reply-To: <20080924033538.GE9790@stlux503.dsto.defence.gov.au> References: <1222173505.80882.15.camel@buffy.york.ac.uk> <48D93006.7050400@root.org> <20080924033538.GE9790@stlux503.dsto.defence.gov.au> Message-ID: <48D9C592.4050103@root.org> 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 gavin at FreeBSD.org Thu Sep 25 02:26:49 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Sep 25 02:26:55 2008 Subject: kern/127581: [patch] [acpi_sony] Add support for more Sony features Message-ID: <200809250226.m8P2QmMA080519@freefall.freebsd.org> 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 Jahanshah_Rashidian at gmx.de Thu Sep 25 17:25:13 2008 From: Jahanshah_Rashidian at gmx.de (Jahanshah Rashidian) Date: Thu Sep 25 17:25:24 2008 Subject: The Walls of Auschwitz Message-ID: <20080925170943.JHJT12744.hrndva-omta01.mail.rr.com@2ao1z> 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 robert.moore at intel.com Fri Sep 26 19:49:56 2008 From: robert.moore at intel.com (Moore, Robert) Date: Fri Sep 26 19:52:59 2008 Subject: ACPICA version 20080926 released Message-ID: <4911F71203A09E4D9981D27F9D83085876770B@orsmsx503.amr.corp.intel.com> 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 From freebsd at abv.bg Sat Sep 27 15:47:00 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Sat Sep 27 15:47:07 2008 Subject: ACPICA version 20080926 released Message-ID: <2079751158.340791.1222529230663.JavaMail.apache@mail52.abv.bg> 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 From bugmaster at FreeBSD.org Mon Sep 29 11:06:46 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:06:52 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200809291106.m8TB6jsF040696@freefall.freebsd.org> 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/127581 acpi [patch] [acpi_sony] Add support for more Sony features 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 42 problems total.