From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 18 18:48:35 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4AAAA3B for ; Sun, 18 Nov 2012 18:48:35 +0000 (UTC) (envelope-from stefan.horomnea@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 396028FC12 for ; Sun, 18 Nov 2012 18:48:34 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hj6so2669346wib.13 for ; Sun, 18 Nov 2012 10:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UGDrVOHqavxlhNb4j+jjcL85m6ExA+5axO0T8Lmym9I=; b=egW+CQwhbVTirS+fDgCtX4C23MSN7wzJeVoC6SpS/E+jgfIGkCCrtSLjEAA76C78MT 4pnasDYYaxga3Mk68iYgfPZE5XsD3vAHRuVfSh9mqPjmUdoOev3wzoV+fDLzoiB85rr7 ygVOT1PTqC7QH6KZtY3Zw6MHBDQSZMoI+1Gp8DEwD4BhGucbBTPNwn4zRVU8uZbZ7bdE 20rnPFBvzjRCvQY3rcekPfZTOqZ2+IpCwvfksEczlrJ4nbBKPicZXumgL2KAzT7sKLmu 35I/1VtV8jeWKQo6pweVEAbQ7jQyVksh4yLyf4A+LunZV5nSP5jNQamU+xEh1CSly+lP f1jQ== MIME-Version: 1.0 Received: by 10.180.94.41 with SMTP id cz9mr5984640wib.2.1353264512798; Sun, 18 Nov 2012 10:48:32 -0800 (PST) Received: by 10.194.65.70 with HTTP; Sun, 18 Nov 2012 10:48:32 -0800 (PST) In-Reply-To: <50A572A1.5030501@gmail.com> References: <50A12DF9.8090107@gmail.com> <20121113082044.GB96846@e-new.0x20.net> <50A572A1.5030501@gmail.com> Date: Sun, 18 Nov 2012 19:48:32 +0100 Message-ID: Subject: Re: Sleep/resume in FreeBSD 9 on a ThinkPad From: Stefan Horomnea To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: smithi@nimnet.asn.au X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2012 18:48:35 -0000 Hello again, I hope I have covered in my tests all the suggestions you guys offered. The result is the same: on resume, something happens, and then the computer restarts. Here is the detailed description: ############################################### 1. Test: BIOS update. Result: NOTHING CHANGES ############################################### Matt, thanks for indications here, as Lenovo's website confused me to think that the .iso file works only on Windows. Indeed, they have a small note below that basically says that is OS independent. So I used cdrecord (thanks for this one too) and it worked. Now I have an up-to-date BIOS, and it's nice to know how to do that, but the resume behaves the same. ######################################################## 2. Test: turn off usb devices. Result: NOTHING CHANGES ######################################################## I powered off whatever devices I could find with usbconfig that were power-off-able Details of the test usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON usbconfig -d ugen1.2 power_off usbconfig -d ugen0.2 power_off usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=OFF ugen1.2: at usbus1, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=OFF sysctl hw.pci.do_power_nodriver=3 hw.pci.do_power_nodriver: 0 -> 3 ######################################################### 3. Test: disable stuff in BIOS. Result: NOTHING CHANGES ######################################################### Did not find to much to disable in BIOS. The only stuff I could disable were: Wake on LAN Wireless LAN Which I did, I disabled them, tried sleep command, same result. ####################################################################### 4. Test: Kill X, turn off usb devices, unload the modules I could, all in one test. Result: NOTHING CHANGES ####################################################################### # The modules loaded are: kldstat Id Refs Address Size Name 1 28 0xffffffff80200000 11cd9b0 kernel 2 1 0xffffffff813ce000 45090 linux.ko 3 1 0xffffffff81414000 6600 cuse4bsd.ko 4 1 0xffffffff81612000 328d ng_ubt.ko 5 1 0xffffffff81616000 8b3d ng_hci.ko 6 3 0xffffffff8161f000 a79 ng_bluetooth.ko 7 5 0xffffffff81620000 8e12 netgraph.ko 8 1 0xffffffff81629000 b4a2 ng_l2cap.ko 9 1 0xffffffff81635000 1695e ng_btsocket.ko 10 1 0xffffffff8164c000 1ba9 ng_socket.ko 11 1 0xffffffff8164e000 64a91 radeon.ko 12 1 0xffffffff816b3000 139a7 drm.ko I was able to unload the following: cuse4bsd.ko (/boot/loader.conf) ng_ubt.ko, radeon.ko, drm.ko The rest couldn t be unloaded: Device busy. Should I see what they are and try to tell /boot/loader.conf to not load them ??? ################################################################## 5. Compile a kernel with: no uhci, ohci, ehci, or xhci. Result: NOTHING CHANGES ################################################################# It was the first time to compile a kernel, it was fun to learn how to do it, and I will probably continue doing it :) Of course, after booting with this configuration, I guess I had no usb support. usbconfig command did not return anything. So Matt, I think that is even 'better' than powering off usb devices :) I haven't even tried to log in to KDE, I just went in console and try the sleep command. Same result. cat /sys/amd64/conf/NO_UHCI include GENERIC ident NO_UHCI nodevice uhci # UHCI PCI->USB interface nodevice ohci # OHCI PCI->USB interface nodevice ehci # EHCI PCI->USB interface (USB 2.0) nodevice xhci # XHCI PCI->USB interface (USB 3.0) #### I am not a C programmer, but I think somehow I should be able to rely more on debugging the matter, and maybe with your help, if it is not to complicated, to interpret the results, get close to the problem's root cause and squash it. Thank you guys for your help so far, let me know if you have a recommended path to go further. Stefan On Thu, Nov 15, 2012 at 11:54 PM, matt wrote: > On 11/15/12 13:48, Stefan Horomnea wrote: > > Hi, > > > > After your suggestion, I have searched a bit but found no way so far to > > update my BIOS on the ThinkPad without having Windows install, in order > to > > run the update they provide on the lenovo website. I used all my > partitions > > for FreeBSD, so I do not space to install Windows. So that would be my > last > > resort. > > If you guys know how I can update my BIOS without installing Windows, let > > me know. > > Until then, I will continue with the other tests. > > > > Thank you, > > Stefan > > > > > Search for the bios bootable cd. It should be available in small print > from the Win7 bios update page. Now without a cdrom drive, it gets > tricky, I think I was using a perl script I found somewhere called > eltorito.pl to extract the disk image and just dd'd that to a usb disk. > If you have a CD drive installed, of course it's much easier to just > burn the iso using cdrecord...worked like a charm. > > Matt > From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 19 11:06:40 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAF4413B for ; Mon, 19 Nov 2012 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A599A8FC17 for ; Mon, 19 Nov 2012 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAJB6ec1013214 for ; Mon, 19 Nov 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAJB6eTu013212 for freebsd-acpi@FreeBSD.org; Mon, 19 Nov 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Nov 2012 11:06:40 GMT Message-Id: <201211191106.qAJB6eTu013212@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 11:06:40 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 20 10:35:28 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03DDF4D1 for ; Tue, 20 Nov 2012 10:35:28 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD138FC08 for ; Tue, 20 Nov 2012 10:35:26 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep14-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121120103525.ZKRJ11100.viefep14-int.chello.at@edge02.upcmail.net> for ; Tue, 20 Nov 2012 11:35:25 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id RmbP1k00A2xdvHc02mbPyN; Tue, 20 Nov 2012 11:35:25 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 0CA866D454; Tue, 20 Nov 2012 11:35:23 +0100 (CET) Date: Tue, 20 Nov 2012 11:35:23 +0100 From: Stefan Farfeleder To: freebsd-acpi@freebsd.org Subject: ACPI panic Message-ID: <20121120103522.GB2012@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 10:35:28 -0000 Hi, today I got the following panic on booting. The error seems to be some kind of race condition, as the same kernel booted fine before and afterwards. This is current, r243234. Any additional information required to debug/fix this? Stefan ### mole.fafoe.narf.at dumped core - see /var/crash/vmcore.7 Tue Nov 20 10:44:28 CET 2012 FreeBSD mole.fafoe.narf.at 10.0-CURRENT FreeBSD 10.0-CURRENT #126 r243234M: Sun Nov 18 19:36:28 CET 2012 stefan@mole.fafoe.narf.at:/usr/obj/usr/src/sys/MOLE amd64 panic: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2012 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 10.0-CURRENT #126 r243234M: Sun Nov 18 19:36:28 CET 2012 stefan@mole.fafoe.narf.at:/usr/obj/usr/src/sys/MOLE amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 0x6 Model = 0x17 Stepping = 10 Features=0xbfebfbff Features2=0xc08e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4017496064 (3831 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5ffffff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io pci0: at device 3.0 (no driver attached) atapci0: port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xef87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xefe0-0xefff mem 0xf6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:e4:17:93 uhci0: port 0x6f60-0x6f7f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x6f80-0x6f9f irq 21 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0x6fa0-0x6fbf irq 22 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xf6fdc000-0xf6fdffff irq 21 at device 27.0 on pci0 pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at device 0.0 on pci12 pcib4: at device 28.2 on pci0 pci13: on pcib4 pcib5: at device 28.3 on pci0 pci14: on pcib5 uhci3: port 0x6f00-0x6f1f irq 20 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0x6f20-0x6f3f irq 21 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 cbb0: irq 19 at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xf1bff800-0xf1bfffff irq 17 at device 1.1 on pci3 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 38:4f:c0:00:2a:55:44:90 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2944000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode sdhci_pci0: mem 0xf1bff600-0xf1bff6ff irq 18 at device 1.2 on pci3 sdhci_pci0: 1 slot(s) allocated pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 orm0: at iomem 0xc0000-0xce7ff,0xce800-0xd37ff,0xd3800-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 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 11,14 on hdaa0 pcm1: at nid 15 and 24 on hdaa0 pcm2: at nid 30 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 pass1 at ahcich1 bus 0 scbus3 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) pass2 at ahciem0 bus 0 scbus6 target 0 lun 0 pass2: SEMB S-E-S 2.00 device SMP: AP CPU #1 Launched! uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 Trying to mount root from ufs:/dev/ufsid/4b1812cf9fe773b5 [rw]... <118>Setting hostuuid: 44454c4c-5000-1035-8042-b8c04f4b344a. <118>Setting hostid: 0x33c89956. <118>Entropy harvesting: interrupts ethernet point_to_point Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10116 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802b5820 stack pointer = 0x28:0xffffff811fe4f490 frame pointer = 0x28:0xffffff811fe4f4c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 52 (sysctl) Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/kernel/if_iwn.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwn.ko Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwn5000fw.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump (textdump=0) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=0) at pcpu.h:229 #1 0xffffffff802bec2e in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff802be7f4 in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff802be4e2 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff802c0dc0 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff804c15de in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff806ee845 in trap_fatal (frame=0xffffff811fe4f3e0, eva=) at /usr/src/sys/amd64/amd64/trap.c:867 #7 0xffffffff806eeae6 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:698 #8 0xffffffff806ee1fc in trap (frame=0xffffff811fe4f3e0) at /usr/src/sys/amd64/amd64/trap.c:463 #9 0xffffffff806d8dc3 in calltrap () at /tmp/exception-EAhiLL.s:142 #10 0xffffffff802b5820 in AcpiOsAcquireObject (Cache=0xfffffe000292a700) at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:310 #11 0xffffffff802b8441 in AcpiUtCreateInternalObjectDbg ( ModuleName=0xffffffff8074a2f6 "dsutils", LineNumber=703, ComponentId=64, Type=1) at /usr/src/sys/contrib/dev/acpica/components/utilities/utobject.c:437 #12 0xffffffff8029bf65 in AcpiDsCreateOperand (WalkState=0xfffffe000618b800, Arg=0xfffffe00041b3bc0, ArgIndex=) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:703 #13 0xffffffff8029c062 in AcpiDsCreateOperands (WalkState=0xfffffe000618b800, FirstArg=) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:798 #14 0xffffffff8029c507 in AcpiDsExecEndOp (WalkState=0xfffffe000618b800) at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dswexec.c:449 #15 0xffffffff802afe04 in AcpiPsParseLoop (WalkState=0xfffffe000618b800) at /usr/src/sys/contrib/dev/acpica/components/parser/psloop.c:1276 #16 0xffffffff802b068d in AcpiPsParseAml (WalkState=) at /usr/src/sys/contrib/dev/acpica/components/parser/psparse.c:525 #17 0xffffffff802b11e7 in AcpiPsExecuteMethod (Info=0xfffffe0006191c80) at /usr/src/sys/contrib/dev/acpica/components/parser/psxface.c:368 #18 0xffffffff802aac16 in AcpiNsEvaluate (Info=0xfffffe0006191c80) at /usr/src/sys/contrib/dev/acpica/components/namespace/nseval.c:193 #19 0xffffffff802add48 in AcpiEvaluateObject (Handle=0xfffffe0002a09280, Pathname=, ExternalParams=, ReturnBuffer=0xffffff811fe4f7c0) at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289 #20 0xffffffff802ce378 in acpi_cmbat_get_bst (arg=0xfffffe0002a3d200) at /usr/src/sys/dev/acpica/acpi_cmbat.c:258 #21 0xffffffff802ce202 in acpi_cmbat_bst (dev=0xfffffe0002a3d200, bstp=0xfffffe0006125300) at /usr/src/sys/dev/acpica/acpi_cmbat.c:419 #22 0xffffffff802cd2ef in acpi_battery_get_battinfo (dev=0x0, battinfo=0xffffffff80a5d380) at acpi_if.h:142 #23 0xffffffff802cd91f in acpi_battery_sysctl (oidp=0xfffffe000418c500, arg1=, arg2=64, req=0xffffff811fe4f968) at /usr/src/sys/dev/acpica/acpi_battery.c:428 #24 0xffffffff80496c8c in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 #25 0xffffffff80497248 in userland_sysctl (td=, name=0xffffff811fe4fa30, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=535099728) at /usr/src/sys/kern/kern_sysctl.c:1623 #26 0xffffffff80497034 in sys___sysctl (td=0xfffffe00041a5900, uap=0xffffff811fe4fb40) at /usr/src/sys/kern/kern_sysctl.c:1549 #27 0xffffffff806eef0e in amd64_syscall (td=0xfffffe00041a5900, traced=0) at subr_syscall.c:135 #28 0xffffffff806d90ab in Xfast_syscall () at /tmp/exception-EAhiLL.s:292 #29 0x000000080093456a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 20 22:55:41 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF220F6; Tue, 20 Nov 2012 22:55:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DA73E8FC12; Tue, 20 Nov 2012 22:55:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02420; Wed, 21 Nov 2012 00:55:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TawjC-000EKt-RH; Wed, 21 Nov 2012 00:55:38 +0200 Message-ID: <50AC0A68.8070906@FreeBSD.org> Date: Wed, 21 Nov 2012 00:55:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> In-Reply-To: <20121120103522.GB2012@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 22:55:41 -0000 on 20/11/2012 12:35 Stefan Farfeleder said the following: > Hi, > > today I got the following panic on booting. The error seems to be some > kind of race condition, as the same kernel booted fine before and > afterwards. This is current, r243234. > > Any additional information required to debug/fix this? [snip] This indeed looks like a heisenbug that happens to FreeBSD users now and then (google for AcpiOsAcquireObject panic). I am trying a verify a certain theory... just on the chance that this issue happens again, could you please try the following debugging patch? Index: sys/contrib/dev/acpica/components/utilities/utdelete.c =================================================================== --- sys/contrib/dev/acpica/components/utilities/utdelete.c (revision 243265) +++ sys/contrib/dev/acpica/components/utilities/utdelete.c (working copy) @@ -441,7 +441,7 @@ "Obj %p Refs=%X, can't decrement! (Set to 0)\n", Object, NewCount)); - NewCount = 0; + NewCount = *(volatile UINT16*)NULL; } else { I hope that this compiles. The point is to induce a panic sooner rather than later. > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x10116 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff802b5820 > stack pointer = 0x28:0xffffff811fe4f490 > frame pointer = 0x28:0xffffff811fe4f4c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 52 (sysctl) > > Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/kernel/if_iwn.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_iwn.ko > Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/iwn5000fw.ko > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 doadump (textdump=0) at pcpu.h:229 > 229 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:229 > #1 0xffffffff802bec2e in db_dump (dummy=, dummy2=0, > dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 > #2 0xffffffff802be7f4 in db_command (last_cmdp=, > cmd_table=, dopager=1) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xffffffff802be4e2 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:502 > #4 0xffffffff802c0dc0 in db_trap (type=, code=0) > at /usr/src/sys/ddb/db_main.c:231 > #5 0xffffffff804c15de in kdb_trap (type=12, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff806ee845 in trap_fatal (frame=0xffffff811fe4f3e0, > eva=) at /usr/src/sys/amd64/amd64/trap.c:867 > #7 0xffffffff806eeae6 in trap_pfault (frame=0x0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:698 > #8 0xffffffff806ee1fc in trap (frame=0xffffff811fe4f3e0) > at /usr/src/sys/amd64/amd64/trap.c:463 > #9 0xffffffff806d8dc3 in calltrap () at /tmp/exception-EAhiLL.s:142 > #10 0xffffffff802b5820 in AcpiOsAcquireObject (Cache=0xfffffe000292a700) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utcache.c:310 > #11 0xffffffff802b8441 in AcpiUtCreateInternalObjectDbg ( > ModuleName=0xffffffff8074a2f6 "dsutils", LineNumber=703, ComponentId=64, > Type=1) > at /usr/src/sys/contrib/dev/acpica/components/utilities/utobject.c:437 > #12 0xffffffff8029bf65 in AcpiDsCreateOperand (WalkState=0xfffffe000618b800, > Arg=0xfffffe00041b3bc0, ArgIndex=) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:703 > #13 0xffffffff8029c062 in AcpiDsCreateOperands (WalkState=0xfffffe000618b800, > FirstArg=) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dsutils.c:798 > #14 0xffffffff8029c507 in AcpiDsExecEndOp (WalkState=0xfffffe000618b800) > at /usr/src/sys/contrib/dev/acpica/components/dispatcher/dswexec.c:449 > #15 0xffffffff802afe04 in AcpiPsParseLoop (WalkState=0xfffffe000618b800) > at /usr/src/sys/contrib/dev/acpica/components/parser/psloop.c:1276 > #16 0xffffffff802b068d in AcpiPsParseAml (WalkState=) > at /usr/src/sys/contrib/dev/acpica/components/parser/psparse.c:525 > #17 0xffffffff802b11e7 in AcpiPsExecuteMethod (Info=0xfffffe0006191c80) > at /usr/src/sys/contrib/dev/acpica/components/parser/psxface.c:368 > #18 0xffffffff802aac16 in AcpiNsEvaluate (Info=0xfffffe0006191c80) > at /usr/src/sys/contrib/dev/acpica/components/namespace/nseval.c:193 > #19 0xffffffff802add48 in AcpiEvaluateObject (Handle=0xfffffe0002a09280, > Pathname=, ExternalParams=, > ReturnBuffer=0xffffff811fe4f7c0) > at /usr/src/sys/contrib/dev/acpica/components/namespace/nsxfeval.c:289 > #20 0xffffffff802ce378 in acpi_cmbat_get_bst (arg=0xfffffe0002a3d200) > at /usr/src/sys/dev/acpica/acpi_cmbat.c:258 > #21 0xffffffff802ce202 in acpi_cmbat_bst (dev=0xfffffe0002a3d200, > bstp=0xfffffe0006125300) at /usr/src/sys/dev/acpica/acpi_cmbat.c:419 > #22 0xffffffff802cd2ef in acpi_battery_get_battinfo (dev=0x0, > battinfo=0xffffffff80a5d380) at acpi_if.h:142 > #23 0xffffffff802cd91f in acpi_battery_sysctl (oidp=0xfffffe000418c500, > arg1=, arg2=64, req=0xffffff811fe4f968) > at /usr/src/sys/dev/acpica/acpi_battery.c:428 > #24 0xffffffff80496c8c in sysctl_root (arg1=, > arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 > #25 0xffffffff80497248 in userland_sysctl (td=, > name=0xffffff811fe4fa30, namelen=, > old=, oldlenp=, > inkernel=, new=, > newlen=, retval=, > flags=535099728) at /usr/src/sys/kern/kern_sysctl.c:1623 > #26 0xffffffff80497034 in sys___sysctl (td=0xfffffe00041a5900, > uap=0xffffff811fe4fb40) at /usr/src/sys/kern/kern_sysctl.c:1549 > #27 0xffffffff806eef0e in amd64_syscall (td=0xfffffe00041a5900, traced=0) > at subr_syscall.c:135 > #28 0xffffffff806d90ab in Xfast_syscall () at /tmp/exception-EAhiLL.s:292 > #29 0x000000080093456a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 21 10:48:46 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D775FDFA; Wed, 21 Nov 2012 10:48:46 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id CD8B28FC0C; Wed, 21 Nov 2012 10:48:45 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121121104841.NWCU26940.viefep19-int.chello.at@edge03.upcmail.net>; Wed, 21 Nov 2012 11:48:41 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id SAoh1k00m2xdvHc03Aohtk; Wed, 21 Nov 2012 11:48:41 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 2E26C6D465; Wed, 21 Nov 2012 11:48:41 +0100 (CET) Date: Wed, 21 Nov 2012 11:48:41 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121121104840.GA1468@mole.fafoe.narf.at> References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AC0A68.8070906@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:48:47 -0000 On Wed, Nov 21, 2012 at 12:55:36AM +0200, Andriy Gapon wrote: > on 20/11/2012 12:35 Stefan Farfeleder said the following: > > Hi, > > > > today I got the following panic on booting. The error seems to be some > > kind of race condition, as the same kernel booted fine before and > > afterwards. This is current, r243234. > > > > Any additional information required to debug/fix this? > [snip] > > This indeed looks like a heisenbug that happens to FreeBSD users now and then > (google for AcpiOsAcquireObject panic). > I am trying a verify a certain theory... just on the chance that this issue > happens again, could you please try the following debugging patch? > > Index: sys/contrib/dev/acpica/components/utilities/utdelete.c > =================================================================== > --- sys/contrib/dev/acpica/components/utilities/utdelete.c (revision 243265) > +++ sys/contrib/dev/acpica/components/utilities/utdelete.c (working copy) > @@ -441,7 +441,7 @@ > "Obj %p Refs=%X, can't decrement! (Set to 0)\n", > Object, NewCount)); > > - NewCount = 0; > + NewCount = *(volatile UINT16*)NULL; > } > else > { > > > I hope that this compiles. The point is to induce a panic sooner rather than later. Thanks. I've applied this and will report back if it triggers a panic. From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 08:18:42 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2033BF16; Thu, 22 Nov 2012 08:18:42 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6178FC12; Thu, 22 Nov 2012 08:18:40 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep17-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20121122081832.IPKT7658.viefep17-int.chello.at@edge03.upcmail.net>; Thu, 22 Nov 2012 09:18:32 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id SYJY1k0182xdvHc03YJYZE; Thu, 22 Nov 2012 09:18:32 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 4B46F6D449; Thu, 22 Nov 2012 09:18:32 +0100 (CET) Date: Thu, 22 Nov 2012 09:18:32 +0100 From: Stefan Farfeleder To: Andriy Gapon Subject: Re: ACPI panic Message-ID: <20121122081831.GA1483@mole.fafoe.narf.at> References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121121104840.GA1468@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 08:18:42 -0000 On Wed, Nov 21, 2012 at 11:48:41AM +0100, Stefan Farfeleder wrote: > On Wed, Nov 21, 2012 at 12:55:36AM +0200, Andriy Gapon wrote: > > on 20/11/2012 12:35 Stefan Farfeleder said the following: > > > Hi, > > > > > > today I got the following panic on booting. The error seems to be some > > > kind of race condition, as the same kernel booted fine before and > > > afterwards. This is current, r243234. > > > > > > Any additional information required to debug/fix this? > > [snip] > > > > This indeed looks like a heisenbug that happens to FreeBSD users now and then > > (google for AcpiOsAcquireObject panic). > > I am trying a verify a certain theory... just on the chance that this issue > > happens again, could you please try the following debugging patch? > > > > Index: sys/contrib/dev/acpica/components/utilities/utdelete.c > > =================================================================== > > --- sys/contrib/dev/acpica/components/utilities/utdelete.c (revision 243265) > > +++ sys/contrib/dev/acpica/components/utilities/utdelete.c (working copy) > > @@ -441,7 +441,7 @@ > > "Obj %p Refs=%X, can't decrement! (Set to 0)\n", > > Object, NewCount)); > > > > - NewCount = 0; > > + NewCount = *(volatile UINT16*)NULL; > > } > > else > > { > > > > > > I hope that this compiles. The point is to induce a panic sooner rather than later. > > Thanks. I've applied this and will report back if it triggers a panic. I'm afraid the AcpiOsAcquireObject panic is not directly related to reference counting. I had the very same panic today with your patch. Stefan From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 10:24:58 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CEE4A6E; Thu, 22 Nov 2012 10:24:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2508FC0C; Thu, 22 Nov 2012 10:24:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA21477; Thu, 22 Nov 2012 12:24:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TbTxn-000GnN-Kv; Thu, 22 Nov 2012 12:24:55 +0200 Message-ID: <50ADFD75.10709@FreeBSD.org> Date: Thu, 22 Nov 2012 12:24:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> In-Reply-To: <20121122081831.GA1483@mole.fafoe.narf.at> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 10:24:58 -0000 on 22/11/2012 10:18 Stefan Farfeleder said the following: > I'm afraid the AcpiOsAcquireObject panic is not directly related to > reference counting. I had the very same panic today with your patch. OK, let's try to attack it from a different angle. Please try this patch: diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c b/sys/contrib/dev/acpica/components/utilities/utcache.c index b8efa68..a3d964a 100644 --- a/sys/contrib/dev/acpica/components/utilities/utcache.c +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c @@ -226,6 +226,22 @@ AcpiOsReleaseObject ( return (AE_BAD_PARAMETER); } + (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES); + char *Curr; + char *Next; + Next = Cache->ListHead; + while (Next) + { + Curr = Next; + Next = *(ACPI_CAST_INDIRECT_PTR (char, + &(((char *) Curr)[Cache->LinkOffset]))); + if (Object == Curr) { + ACPI_ERROR ((AE_INFO, "freeing a free object %p\n", Object)); + Curr = *(volatile char **)NULL; /* induce crash */ + } + } + (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); + /* If cache is full, just free this object */ if (Cache->CurrentDepth >= Cache->MaxDepth) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 10:34:30 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32858CF6; Thu, 22 Nov 2012 10:34:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 459458FC0C; Thu, 22 Nov 2012 10:34:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA21618; Thu, 22 Nov 2012 12:34:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TbU71-000GoL-BE; Thu, 22 Nov 2012 12:34:27 +0200 Message-ID: <50ADFFB2.1000108@FreeBSD.org> Date: Thu, 22 Nov 2012 12:34:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> In-Reply-To: <50ADFD75.10709@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 10:34:30 -0000 on 22/11/2012 12:24 Andriy Gapon said the following: > on 22/11/2012 10:18 Stefan Farfeleder said the following: >> I'm afraid the AcpiOsAcquireObject panic is not directly related to >> reference counting. I had the very same panic today with your patch. > > OK, let's try to attack it from a different angle. > Please try this patch: [snip] Or better this one: diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c b/sys/contrib/dev/acpica/components/utilities/utcache.c index b8efa68..09b77b2 100644 --- a/sys/contrib/dev/acpica/components/utilities/utcache.c +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c @@ -226,6 +226,22 @@ AcpiOsReleaseObject ( return (AE_BAD_PARAMETER); } + (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES); + char *Curr; + char *Next; + Next = Cache->ListHead; + while (Next) + { + Curr = Next; + Next = *(ACPI_CAST_INDIRECT_PTR (char, + &(((char *) Curr)[Cache->LinkOffset]))); + if (Object == Curr) { + ACPI_ERROR ((AE_INFO, "freeing a free object %p\n", Object)); + Curr = *(volatile char **)NULL; /* induce crash */ + } + } + (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); + /* If cache is full, just free this object */ if (Cache->CurrentDepth >= Cache->MaxDepth) @@ -312,6 +328,11 @@ AcpiOsAcquireObject ( Cache->CurrentDepth--; + if (*(const char *) Object != 0xCA) { + ACPI_ERROR ((AE_INFO, "detected use after free %p\n", Object)); + Object = *(volatile char **)NULL; /* induce crash */ + } + ACPI_MEM_TRACKING (Cache->Hits++); ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Object %p from %s cache\n", Object, Cache->ListName)); -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 10:59:13 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C9C14A8; Thu, 22 Nov 2012 10:59:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 299618FC08; Thu, 22 Nov 2012 10:59:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA21903; Thu, 22 Nov 2012 12:59:10 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TbUUw-000GqX-Hs; Thu, 22 Nov 2012 12:59:10 +0200 Message-ID: <50AE057D.8060808@FreeBSD.org> Date: Thu, 22 Nov 2012 12:59:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: ACPI panic References: <20121120103522.GB2012@mole.fafoe.narf.at> <50AC0A68.8070906@FreeBSD.org> <20121121104840.GA1468@mole.fafoe.narf.at> <20121122081831.GA1483@mole.fafoe.narf.at> <50ADFD75.10709@FreeBSD.org> <50ADFFB2.1000108@FreeBSD.org> In-Reply-To: <50ADFFB2.1000108@FreeBSD.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 10:59:13 -0000 A patch that should actually compile, finally. BTW, it's probably better to replace the NULL dereference trick with a simple panic call in the first patch too. diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c b/sys/contrib/dev/acpica/components/utilities/utcache.c index b8efa68..edd9e4f 100644 --- a/sys/contrib/dev/acpica/components/utilities/utcache.c +++ b/sys/contrib/dev/acpica/components/utilities/utcache.c @@ -226,6 +226,21 @@ AcpiOsReleaseObject ( return (AE_BAD_PARAMETER); } + (void) AcpiUtAcquireMutex (ACPI_MTX_CACHES); + char *Curr; + char *Next; + Next = Cache->ListHead; + while (Next) + { + Curr = Next; + Next = *(ACPI_CAST_INDIRECT_PTR (char, + &(((char *) Curr)[Cache->LinkOffset]))); + if (Object == Curr) { + panic("freeing a free object %p", Object); + } + } + (void) AcpiUtReleaseMutex (ACPI_MTX_CACHES); + /* If cache is full, just free this object */ if (Cache->CurrentDepth >= Cache->MaxDepth) @@ -312,6 +327,10 @@ AcpiOsAcquireObject ( Cache->CurrentDepth--; + if (*(const unsigned char *) Object != 0xCA) { + panic("detected use after free %p\n", Object); + } + ACPI_MEM_TRACKING (Cache->Hits++); ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Object %p from %s cache\n", Object, Cache->ListName)); -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 12:39:50 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F7D7870; Thu, 22 Nov 2012 12:39:50 +0000 (UTC) (envelope-from Tom.Lislegaard@proact.no) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by mx1.freebsd.org (Postfix) with ESMTP id BA59F8FC08; Thu, 22 Nov 2012 12:39:49 +0000 (UTC) Received: from mail42-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Nov 2012 12:39:42 +0000 Received: from mail42-am1 (localhost [127.0.0.1]) by mail42-am1-R.bigfish.com (Postfix) with ESMTP id 5488134019E; Thu, 22 Nov 2012 12:39:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:212.214.215.133; KIP:(null); UIP:(null); IPV:NLI; H:semtaout01.proact.se; RD:semtaout01.proact.se; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI542M1432Izz1de0h1d18h1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail42-am1 (localhost.localdomain [127.0.0.1]) by mail42-am1 (MessageSwitch) id 1353587980361081_6246; Thu, 22 Nov 2012 12:39:40 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.231]) by mail42-am1.bigfish.com (Postfix) with ESMTP id 4C5F93C00F7; Thu, 22 Nov 2012 12:39:40 +0000 (UTC) Received: from semtaout01.proact.se (212.214.215.133) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Nov 2012 12:39:39 +0000 Received: from Semail04.proact.local (unknown [10.7.1.58]) by semtaout01.proact.se (Postfix) with ESMTP id 1EE545727C; Thu, 22 Nov 2012 13:39:34 +0100 (CET) Received: from SEMAIL03.proact.local ([fe80::a52b:385d:b44f:ecb9]) by Semail04.proact.local ([fe80::885:6e64:c1e6:dcf1%20]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 13:39:33 +0100 From: Tom Lislegaard To: 'Andriy Gapon' Subject: RE: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource] Thread-Topic: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource] Thread-Index: AQHNvc81+Z+//tujgE2NCdmsWuXGgZfhbFxQgAAIXwCABmv7oP//9iUAgAFRP4CADLUHAA== Date: Thu, 22 Nov 2012 12:39:32 +0000 Message-ID: References: <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> <509B8F15.4030300@FreeBSD.org> <509BDF86.3080502@FreeBSD.org> <509D091A.8080108@FreeBSD.org> <50A263E8.2060707@FreeBSD.org> <50A37ECF.1070803@FreeBSD.org> In-Reply-To: <50A37ECF.1070803@FreeBSD.org> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.1.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: proact.no Cc: "freebsd-acpi@FreeBSD.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 12:39:50 -0000 > -----Original Message----- > From: Andriy Gapon [mailto:avg@FreeBSD.org] > Sent: 14. november 2012 12:22 > To: Tom Lislegaard > Cc: freebsd-acpi@FreeBSD.org > Subject: Re: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_lis= t_unreserve: can't find > resource] >=20 > on 13/11/2012 17:14 Andriy Gapon said the following: > > I have a better patch, which I tested at least. I'll send it to you so= on-ish. >=20 > Here is a tested version of the ref-count patch (still a little bit exper= imental): > http://people.freebsd.org/~avg/acpi-ref-count-exp.diff >=20 > -- > Andriy Gapon I've had the patched kernel running for nearly one week without any panic o= r other acpi related problems so I think it's safe to say this patch is goo= d. Thanks. Any idea when this (and the previous patch for the resource_list_unreserve = problem) can be committed? I suppose it will have to be sometime after 9.1-= RELEASE? -tom From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 13:08:04 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B044216 for ; Thu, 22 Nov 2012 13:08:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 65DA18FC08 for ; Thu, 22 Nov 2012 13:08:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA23269; Thu, 22 Nov 2012 15:07:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50AE23A8.8040706@FreeBSD.org> Date: Thu, 22 Nov 2012 15:07:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find resource] References: <5093BECC.1030709@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> <5097F24D.7040206@FreeBSD.org> <50995C8F.3040309@FreeBSD.org> <509B8F15.4030300@FreeBSD.org> <509BDF86.3080502@FreeBSD.org> <509D091A.8080108@FreeBSD.org> <50A263E8.2060707@FreeBSD.org> <50A37ECF.1070803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 13:08:04 -0000 on 22/11/2012 14:39 Tom Lislegaard said the following: > > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: 14. november 2012 12:22 >> To: Tom Lislegaard >> Cc: freebsd-acpi@FreeBSD.org >> Subject: Re: AcpiOsAcquireObject crash [Was: 9-Stable panic: resource_list_unreserve: can't find >> resource] >> >> on 13/11/2012 17:14 Andriy Gapon said the following: >>> I have a better patch, which I tested at least. I'll send it to you soon-ish. >> >> Here is a tested version of the ref-count patch (still a little bit experimental): >> http://people.freebsd.org/~avg/acpi-ref-count-exp.diff > > I've had the patched kernel running for nearly one week without any panic or other acpi related problems so I think it's safe to say this patch is good. Thanks. > > Any idea when this (and the previous patch for the resource_list_unreserve problem) can be committed? I suppose it will have to be sometime after 9.1-RELEASE? One part of the acpi_cpu patch I am going to commit rather soon. For the other part I am going to wait (and more actively push) for a review for some more time. Regarding the ref. count patch - given the probabilistic nature of the bug and my being not sure about the need for the change I am going to investigate / analyze the issue further before making any decision. That's my current plan. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 22 14:53:29 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6624D6D; Thu, 22 Nov 2012 14:53:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A57478FC13; Thu, 22 Nov 2012 14:53:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA24297; Thu, 22 Nov 2012 16:53:27 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50AE3C66.2050207@FreeBSD.org> Date: Thu, 22 Nov 2012 16:53:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Subject: [rfc] bind curthread to target cpu for _CST change notification X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 14:53:29 -0000 I would like to propose the following patch which should kill two birds with one stone: - avoid race in acpi_cpu_cx_cst if more than one notifications occur in a rapid succession for the same CPU and end up being concurrently handled by ACPI taskqeue threads - avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access resources being updated by the former What do you think? Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (revision 242854) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@ -1047,7 +1047,16 @@ return; /* Update the list of Cx states. */ + thread_lock(curthread); + sched_bind(curthread, sc->cpu_pcpu->pc_cpuid); + thread_unlock(curthread); + critical_enter(); acpi_cpu_cx_cst(sc); + critical_exit(); + thread_lock(curthread); + sched_unbind(curthread); + thread_unlock(curthread); + acpi_cpu_cx_list(sc); ACPI_SERIAL_BEGIN(cpu); -- Andriy Gapon