From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 00:15:43 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DEC516A4CE; Sun, 21 Nov 2004 00:15:43 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D4743D1F; Sun, 21 Nov 2004 00:15:42 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP id IBA74465; Sat, 20 Nov 2004 16:15:42 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B89105D04; Sat, 20 Nov 2004 16:15:41 -0800 (PST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: John Baldwin In-reply-to: Your message of "Thu, 04 Nov 2004 17:30:04 EST." <200411041730.04081.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-17318153980" Date: Sat, 20 Nov 2004 16:15:41 -0800 From: "Kevin Oberman" Message-Id: <20041121001541.B89105D04@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 00:15:43 -0000 This is a multipart MIME message. --==_Exmh_-17318153980 Content-Type: text/plain; charset=us-ascii > From: John Baldwin > Date: Thu, 4 Nov 2004 17:30:04 -0500 > > On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > > From: John Baldwin > > > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > > > > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > > > From: John Baldwin > > > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > > > Kevin Oberman wrote: > > > > > > > > > > It looks like interrupts from the Ethernet are not > > > > > > > > > > delivered without ACPI, but that is hardly your problem. I > > > > > > > > > > have over-ridden the black-list and things are back to > > > > > > > > > > normal. > > > > > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that > > > > > > > > > irq routing in Windows uses multiple info sources including > > > > > > > > > _PIR and $PIR. John Baldwin has patches to do this for us > > > > > > > > > too. > > > > > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite > > > > > > > > a while. The patches I have are to make the acpi_pci_link code > > > > > > > > work more like the $PIR code already does. It doesn't change > > > > > > > > the ACPI code to actually use $PIR or the MPTable though. I > > > > > > > > can try to look at why the ethernet device doesn't get > > > > > > > > interrupts correctly if you can provide verbose ACPI and > > > > > > > > non-ACPI dmesgs to look at. > > > > > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > > > interrupts that I had not previously noted, but they seen to be > > > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates > > > > > > > it should be on IRQ 6. interrupt total > > > > > > > rate > > > > > > > irq0: clk 4242251 99 > > > > > > > irq1: atkbd0 3 0 > > > > > > > irq7: ppc0 1 0 > > > > > > > irq8: rtc 5430044 127 > > > > > > > irq10: xl0 13699 0 > > > > > > > irq13: npx0 1 0 > > > > > > > irq14: ata0 166980 3 > > > > > > > irq15: ata1 136 0 > > > > > > > Total 9853115 232 > > > > > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an > > > > > > option for your link devices but ACPI does. In the non-APCI case > > > > > > we use IRQ 10 for both xl0 and pcm0. Are you saying that in that > > > > > > case pcm0 works but xl0 does not? > > > > > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > > > first tone in the file plays continuously, like there are no > > > > > interrupts from the sound card. :-) > > > > > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of > > > > the box, you can try setting a hint to force the link for your sound > > > > card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > > > maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > > > > > Actually, the $PIR code won't let you use an invalid IRQ currently, but > > > this patch lets it do so. I'm curious if you could try booting with this > > > patch with ACPI disabled and using an appropriate tunable (such as > > > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > > routed. If this does work, I'd like to try another patch as well that > > > would help it to work out-of-the-box for the non-ACPI case. Thanks. > > > > John, > > > > I have not forgotten this, but remote testing when re-boots are required > > is a bit difficult. My wife helped me a bit yesterday, but she is a > > Solaris type and I need to step her through things command by command, > > so it's a bit tedious. > > That's ok, take your time, this isn't super critical. O.K. I tried the loadable (hw.pci.link.0x4.irq="6"), but it still did not work. I got the expected message: $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 but still no interrupts from the network card. Both the network card and the sound card claim to be using the specified IRQ (I tried both 6 and 10): pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 but 'vmstat -i' did not list IRQ6 as being in use. I will attach the full verbose boot. Thanks again for looking at this. -- 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 --==_Exmh_-17318153980 Content-Type: text/plain ; name="dmesg.log"; charset=us-ascii Content-Description: dmesg.log Content-Disposition: attachment; filename="dmesg.log" Nov 20 15:50:48 kzin syslogd: kernel boot file is /boot/kernel/kernel Copyright (c) 1992-2004 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 5.3-STABLE #60: Mon Nov 1 21:54:55 PST 2004 oberman@kzin.es.net:/usr/obj/usr/src/sys/KZIN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x80000800 real memory = 100646912 (95 MB) avail memory = 92938240 (88 MB) K6-family MTRR support enabled (2 registers) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:da:80:4b:43 atapci0: port 0xd000-0xd00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ppc0: port 0x778-0x77b,0x378-0x37b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 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 atkbdc0: port 0x64,0x60 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 Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc7fff on isa0 pmtimer0 on isa0 fdc0: cannot allocate I/O port (6 ports) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 451023883 Hz quality 800 Timecounters tick every 10.000 msec ad0: 13031MB [26476/16/63] at ata0-master UDMA33 ad2: 13029MB [26473/16/63] at ata1-master UDMA33 acd0: DVDROM at ata1-slave PIO3 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 11.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a --==_Exmh_-17318153980-- From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 00:15:43 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DEC516A4CE; Sun, 21 Nov 2004 00:15:43 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D4743D1F; Sun, 21 Nov 2004 00:15:42 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP id IBA74465; Sat, 20 Nov 2004 16:15:42 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id B89105D04; Sat, 20 Nov 2004 16:15:41 -0800 (PST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: John Baldwin In-reply-to: Your message of "Thu, 04 Nov 2004 17:30:04 EST." <200411041730.04081.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-17318153980" Date: Sat, 20 Nov 2004 16:15:41 -0800 From: "Kevin Oberman" Message-Id: <20041121001541.B89105D04@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 00:15:43 -0000 This is a multipart MIME message. --==_Exmh_-17318153980 Content-Type: text/plain; charset=us-ascii > From: John Baldwin > Date: Thu, 4 Nov 2004 17:30:04 -0500 > > On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > > From: John Baldwin > > > Date: Mon, 1 Nov 2004 17:48:25 -0500 > > > > > > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > > > From: John Baldwin > > > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400 > > > > > > > > > > > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote: > > > > > > > > > Kevin Oberman wrote: > > > > > > > > > > It looks like interrupts from the Ethernet are not > > > > > > > > > > delivered without ACPI, but that is hardly your problem. I > > > > > > > > > > have over-ridden the black-list and things are back to > > > > > > > > > > normal. > > > > > > > > > > > > > > > > > > The reason this system works in Windows without ACPI is that > > > > > > > > > irq routing in Windows uses multiple info sources including > > > > > > > > > _PIR and $PIR. John Baldwin has patches to do this for us > > > > > > > > > too. > > > > > > > > > > > > > > > > $PIR routing already works on FreeBSD and has worked for quite > > > > > > > > a while. The patches I have are to make the acpi_pci_link code > > > > > > > > work more like the $PIR code already does. It doesn't change > > > > > > > > the ACPI code to actually use $PIR or the MPTable though. I > > > > > > > > can try to look at why the ethernet device doesn't get > > > > > > > > interrupts correctly if you can provide verbose ACPI and > > > > > > > > non-ACPI dmesgs to look at. > > > > > > > > > > > > > > I am attaching the files. I do see some oddities with the > > > > > > > interrupts that I had not previously noted, but they seen to be > > > > > > > linked to sound, not the Ethernet. And, for whatever it's worth, > > > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates > > > > > > > it should be on IRQ 6. interrupt total > > > > > > > rate > > > > > > > irq0: clk 4242251 99 > > > > > > > irq1: atkbd0 3 0 > > > > > > > irq7: ppc0 1 0 > > > > > > > irq8: rtc 5430044 127 > > > > > > > irq10: xl0 13699 0 > > > > > > > irq13: npx0 1 0 > > > > > > > irq14: ata0 166980 3 > > > > > > > irq15: ata1 136 0 > > > > > > > Total 9853115 232 > > > > > > > > > > > > First, do you have a floppy drive? IRQ 6 should be used for your > > > > > > floppy drive if so. Note that $PIR says that IRQ 6 is not an > > > > > > option for your link devices but ACPI does. In the non-APCI case > > > > > > we use IRQ 10 for both xl0 and pcm0. Are you saying that in that > > > > > > case pcm0 works but xl0 does not? > > > > > > > > > > The sound card works fine with ACPI but, without ACPI it fails. The > > > > > first tone in the file plays continuously, like there are no > > > > > interrupts from the sound card. :-) > > > > > > > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of > > > > the box, you can try setting a hint to force the link for your sound > > > > card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > > > maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > > > > > Actually, the $PIR code won't let you use an invalid IRQ currently, but > > > this patch lets it do so. I'm curious if you could try booting with this > > > patch with ACPI disabled and using an appropriate tunable (such as > > > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > > routed. If this does work, I'd like to try another patch as well that > > > would help it to work out-of-the-box for the non-ACPI case. Thanks. > > > > John, > > > > I have not forgotten this, but remote testing when re-boots are required > > is a bit difficult. My wife helped me a bit yesterday, but she is a > > Solaris type and I need to step her through things command by command, > > so it's a bit tedious. > > That's ok, take your time, this isn't super critical. O.K. I tried the loadable (hw.pci.link.0x4.irq="6"), but it still did not work. I got the expected message: $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 but still no interrupts from the network card. Both the network card and the sound card claim to be using the specified IRQ (I tried both 6 and 10): pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 but 'vmstat -i' did not list IRQ6 as being in use. I will attach the full verbose boot. Thanks again for looking at this. -- 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 --==_Exmh_-17318153980 Content-Type: text/plain ; name="dmesg.log"; charset=us-ascii Content-Description: dmesg.log Content-Disposition: attachment; filename="dmesg.log" Nov 20 15:50:48 kzin syslogd: kernel boot file is /boot/kernel/kernel Copyright (c) 1992-2004 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 5.3-STABLE #60: Mon Nov 1 21:54:55 PST 2004 oberman@kzin.es.net:/usr/obj/usr/src/sys/KZIN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x80000800 real memory = 100646912 (95 MB) avail memory = 92938240 (88 MB) K6-family MTRR support enabled (2 registers) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:da:80:4b:43 atapci0: port 0xd000-0xd00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ppc0: port 0x778-0x77b,0x378-0x37b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 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 atkbdc0: port 0x64,0x60 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 Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xc7fff on isa0 pmtimer0 on isa0 fdc0: cannot allocate I/O port (6 ports) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 451023883 Hz quality 800 Timecounters tick every 10.000 msec ad0: 13031MB [26476/16/63] at ata0-master UDMA33 ad2: 13029MB [26473/16/63] at ata1-master UDMA33 acd0: DVDROM at ata1-slave PIO3 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 11.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Mounting root from ufs:/dev/ad0s1a --==_Exmh_-17318153980-- From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 01:13:56 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6355416A4CE for ; Sun, 21 Nov 2004 01:13:56 +0000 (GMT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id D091643D31 for ; Sun, 21 Nov 2004 01:13:55 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([138.89.72.171]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041121011355.UMEE4287.out008.verizon.net@RabbitsDen>; Sat, 20 Nov 2004 19:13:55 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Nate Lawson In-Reply-To: <419EF7AD.8050007@root.org> References: <419EF7AD.8050007@root.org> Content-Type: text/plain Date: Sat, 20 Nov 2004 20:12:55 -0500 Message-Id: <1100999575.747.10.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [138.89.72.171] at Sat, 20 Nov 2004 19:13:54 -0600 cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 01:13:56 -0000 On Fri, 2004-11-19 at 23:52 -0800, Nate Lawson wrote: > The attached patch implements setting power states for ACPI (i.e. ISA) > and PCI devices in the suspend/resume path. This may help with some > problems; it's quite likely it may introduce problems. That's why I'd > like it tested. If you have a system that suspends/resumes ok or that > fails, please try it. The likely failure case is a hang in suspend or > resume or a device that doesn't work afterwords. It's pretty > heavy-handed, only avoiding changing power for serial ports since those > are known to cause a hang (which can possibly be fixed by making > sio/uart more aware of power states.) I suspect devices like PCI > bridges may have problems with power changes. > > If you have problems, please let me know the info it prints before the > hang so I can figure out what the problem device is. > > -Nate First, the disclaimer: on my system (Averatec 3150H) entering S3 state only works if I take out infinite loop in acpi_wakeup.c. I don't know whether it still technically enters S3 state or not, but it surely powers down everything in sight, including back light and PCMCIA controller. Battery life (by very unscientific measurements) doubles, which makes me believe, that it is not quite S3 ;) This said, with this patch, only observable difference is that screen goes all-white right before switching off back light and is all-white after resume, switching to normal display shortly afterward. I could not judge whether this behavior is of any interest to you and what additional info (if any) might be required. If there is any, please, let me know and I will be happy to oblige. --- Alexandre "Sunny" Kovalenko. From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 15:16:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ACE816A4CE for ; Sun, 21 Nov 2004 15:16:52 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57A7443D58 for ; Sun, 21 Nov 2004 15:16:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iALFEvOM022706; Sun, 21 Nov 2004 08:15:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 21 Nov 2004 08:15:21 -0700 (MST) Message-Id: <20041121.081521.102766341.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <419EF7AD.8050007@root.org> References: <419EF7AD.8050007@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 15:16:52 -0000 In message: <419EF7AD.8050007@root.org> Nate Lawson writes: : cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : cbb_power: 0V : cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : cbb_power: 0V This looks like a problem to me. Warner From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 15:28:46 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA18216A4CE for ; Sun, 21 Nov 2004 15:28:46 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 563DF43D2F for ; Sun, 21 Nov 2004 15:28:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iALFRblk022869; Sun, 21 Nov 2004 08:27:40 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 21 Nov 2004 08:28:12 -0700 (MST) Message-Id: <20041121.082812.116352579.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <419EF7AD.8050007@root.org> References: <419EF7AD.8050007@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 15:28:46 -0000 In message: <419EF7AD.8050007@root.org> Nate Lawson writes: : The attached patch implements setting power states for ACPI (i.e. ISA) : and PCI devices in the suspend/resume path. This may help with some : problems; it's quite likely it may introduce problems. That's why I'd : like it tested. If you have a system that suspends/resumes ok or that : fails, please try it. The likely failure case is a hang in suspend or : resume or a device that doesn't work afterwords. It's pretty : heavy-handed, only avoiding changing power for serial ports since those : are known to cause a hang (which can possibly be fixed by making : sio/uart more aware of power states.) I suspect devices like PCI : bridges may have problems with power changes. : : If you have problems, please let me know the info it prints before the : hang so I can figure out what the problem device is. I suspect that we'll need finer grain control over the APM case. For APM Bioses, the OS isn't supposed to put devices into lower power states. The APM BIOS generally does this and restores things on resume. APM is somewhat more limited in what it can do, so this makes sense. /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ So if APM implemented the ACPI_PWR_FOR_SLEEP interface, we'd be set. However, there's at leas two problems with this. One is that we don't have a way to get the 'power management' device generically (witness the hacks to get acpi in generic pci code). Second, we don't have a generic power interface, so having APM implement ACPI_ named methods seems a little unsatisfying at best. I'm not sure what powermacs do for their PM stuff, but I'm pretty sure it isn't acpi. Warner From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 21 23:32:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED0716A4CF for ; Sun, 21 Nov 2004 23:32:04 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A53043D46 for ; Sun, 21 Nov 2004 23:32:03 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id IBA74465; Sun, 21 Nov 2004 15:32:02 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8AEB95D04; Sun, 21 Nov 2004 15:32:02 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Fri, 19 Nov 2004 23:52:13 PST." <419EF7AD.8050007@root.org> Date: Sun, 21 Nov 2004 15:32:02 -0800 From: "Kevin Oberman" Message-Id: <20041121233202.8AEB95D04@ptavv.es.net> cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2004 23:32:04 -0000 > Date: Fri, 19 Nov 2004 23:52:13 -0800 > From: Nate Lawson > Sender: owner-freebsd-acpi@freebsd.org > > This is a multi-part message in MIME format. > --------------000406040402060700060908 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > The attached patch implements setting power states for ACPI (i.e. ISA) > and PCI devices in the suspend/resume path. This may help with some > problems; it's quite likely it may introduce problems. That's why I'd > like it tested. If you have a system that suspends/resumes ok or that > fails, please try it. The likely failure case is a hang in suspend or > resume or a device that doesn't work afterwords. It's pretty > heavy-handed, only avoiding changing power for serial ports since those > are known to cause a hang (which can possibly be fixed by making > sio/uart more aware of power states.) I suspect devices like PCI > bridges may have problems with power changes. > > If you have problems, please let me know the info it prints before the > hang so I can figure out what the problem device is. > > -Nate > Nate, I tried the patches on my T30 ThinkPad and had little luck. Without the DPMS patch, the display did not turn off, but the big problem was that the mini-PCI Prism 2.5 card was dead after the resume. I don't have a PCMCIA card in my system at the moment. so I don't know if it would have recovered. Other than the lack of the wireless card, the resume was fine, but my audio was still messed up after the resume. (Running at the raw rate.) I will append my log of the suspends and resumes. The first was before the DPMS patch and the second is after. Let me know if I can supply any other information. I will try suspending with a pcmcia card plugged in a little later. -- 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 Nov 21 12:12:26 puppeteer sudo: oberman : TTY=ttyp1 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/usr/sbin/zzz Nov 21 12:12:27 puppeteer acpi: suspend at 20041121 12:12:27 Nov 21 12:12:29 puppeteer kernel: acpi: _SxD is D3 Nov 21 12:12:29 puppeteer kernel: acpi: _SxD is D2 Nov 21 12:12:29 puppeteer last message repeated 3 times Nov 21 12:12:29 puppeteer kernel: acpi: _SxD is D3 Nov 21 12:12:29 puppeteer last message repeated 5 times Nov 21 12:12:29 puppeteer kernel: cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff Nov 21 12:12:29 puppeteer kernel: cbb_power: 0V Nov 21 12:12:29 puppeteer kernel: cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff Nov 21 12:12:29 puppeteer kernel: cbb_power: 0V Nov 21 12:12:29 puppeteer kernel: wi0: timeout in wi_seek to 149/0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.MEM_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.SIO_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_PR_.CPU_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_TZ_.THM0 into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.LID_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.SLPB into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi: _SxD is D2 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0 into D2 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.PIC_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.TIMR into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.DMAC into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FPU_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.RTC_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.KBD_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.MOU_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FDC_ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FDC_ into D3 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT0 into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT1 into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.AC__ into D3 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.MEM_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.MEM_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.SIO_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.SIO_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_PR_.CPU_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_PR_.CPU_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_TZ_.THM0 into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_TZ_.THM0 into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.LID_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.LID_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.SLPB into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.SLPB into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0 into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0 into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.PIC_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.PIC_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.TIMR into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.TIMR into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.DMAC into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.DMAC into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FPU_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FPU_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.RTC_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.RTC_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.KBD_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.KBD_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.MOU_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.MOU_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FDC_ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FDC_ into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.UART into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.UART into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT0 into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.BAT0 into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT1 into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.BAT1 into D0 Nov 21 12:12:48 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.AC__ into D0 (if supported) Nov 21 12:12:48 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.AC__ into D0 Nov 21 12:12:48 puppeteer kernel: wakeup from sleeping state (slept 00:00:18) Nov 21 12:12:49 puppeteer acpi: resumed at 20041121 12:12:49 Nov 21 12:12:56 puppeteer su: oberman to root on /dev/ttyp1 Nov 21 12:14:58 puppeteer su: oberman to root on /dev/ttyp1 Nov 21 12:15:11 puppeteer kernel: acpi_video0: detached Nov 21 12:15:34 puppeteer kernel: acpi_video0: port 0x3000-0x30ff mem 0xd0100000-0xd010ffff,0xe8000000-0xefffffff irq 11 at device 0.0 on pci1 Nov 21 12:15:43 puppeteer sudo: oberman : TTY=ttyp1 ; PWD=/usr/home/oberman ; USER=root ; COMMAND=/usr/sbin/zzz Nov 21 12:15:44 puppeteer acpi: suspend at 20041121 12:15:44 Nov 21 12:15:46 puppeteer kernel: acpi: _SxD is D3 Nov 21 12:15:46 puppeteer kernel: acpi: _SxD is D2 Nov 21 12:15:46 puppeteer last message repeated 3 times Nov 21 12:15:46 puppeteer kernel: acpi: _SxD is D3 Nov 21 12:15:46 puppeteer last message repeated 5 times Nov 21 12:15:46 puppeteer kernel: cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff Nov 21 12:15:46 puppeteer kernel: cbb_power: 0V Nov 21 12:15:46 puppeteer kernel: cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff Nov 21 12:15:46 puppeteer kernel: cbb_power: 0V Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.MEM_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.SIO_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_PR_.CPU_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_TZ_.THM0 into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.LID_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.SLPB into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi: _SxD is D2 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0 into D2 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi0: failed to set ACPI power state D2 on \_SB_.PCI0: AE_BAD_PARAMETER Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.PIC_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.TIMR into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.DMAC into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FPU_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.RTC_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.KBD_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.MOU_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FDC_ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FDC_ into D3 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT0 into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT1 into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.AC__ into D3 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.MEM_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.MEM_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.SIO_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.SIO_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_PR_.CPU_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_PR_.CPU_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_TZ_.THM0 into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_TZ_.THM0 into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.LID_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.LID_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.SLPB into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.SLPB into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0 into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0 into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.PIC_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.PIC_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.TIMR into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.TIMR into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.DMAC into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.DMAC into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FPU_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FPU_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.RTC_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.RTC_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.KBD_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.KBD_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.MOU_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.MOU_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.FDC_ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.FDC_ into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.UART into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.UART into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT0 into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.BAT0 into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.BAT1 into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.BAT1 into D0 Nov 21 12:16:07 puppeteer kernel: acpi attempting to switch \_SB_.PCI0.LPC_.EC__.AC__ into D0 (if supported) Nov 21 12:16:07 puppeteer kernel: acpi succeeded putting \_SB_.PCI0.LPC_.EC__.AC__ into D0 Nov 21 12:16:07 puppeteer kernel: wakeup from sleeping state (slept 00:00:20) Nov 21 12:16:08 puppeteer acpi: resumed at 20041121 12:16:08 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 22 11:01:53 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E58216A4CE for ; Mon, 22 Nov 2004 11:01:53 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711BD43D67 for ; Mon, 22 Nov 2004 11:01:53 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAMB1r1B075869 for ; Mon, 22 Nov 2004 11:01:53 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAMB1qUh075863 for freebsd-acpi@freebsd.org; Mon, 22 Nov 2004 11:01:52 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 22 Nov 2004 11:01:52 GMT Message-Id: <200411221101.iAMB1qUh075863@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 11:01:53 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/07] kern/53008 acpi [PATCH] genwakecode generates errornously o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2004/01/22] i386/61703 acpi ACPI + Sound + Boot = Reboot o [2004/03/17] kern/64365 acpi ACPI problems f [2004/05/25] i386/67189 acpi ACPI S3 reboot computer on Dell Latitude o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) f [2004/06/23] i386/68219 acpi ACPI + snd_maestro3 problem o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 6 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 22 13:31:54 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CC916A4F5 for ; Mon, 22 Nov 2004 13:31:54 +0000 (GMT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A73F343D1F for ; Mon, 22 Nov 2004 13:31:53 +0000 (GMT) (envelope-from maarfree@xs4all.nl) Received: from webmail.xs4all.nl (webmail9.xs4all.nl [194.109.22.169]) by smtp-vbr15.xs4all.nl (8.12.11/8.12.11) with ESMTP id iAMDVq2n074056 for ; Mon, 22 Nov 2004 14:31:52 +0100 (CET) (envelope-from maarfree@xs4all.nl) Received: from 80.127.55.226 by webmail.xs4all.nl with HTTP; Mon, 22 Nov 2004 14:31:52 +0100 (CET) Message-ID: <12338.80.127.55.226.1101130312.squirrel@80.127.55.226> Date: Mon, 22 Nov 2004 14:31:52 +0100 (CET) From: maarfree@xs4all.nl To: freebsd-acpi@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: 5.3-Production Release -> 5.3-Stable, acpi hangs system X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 13:31:54 -0000 Hi, I upgraded my laptop last weekend, now with acpi enabled the system hangs, without I can boot. 5.3-Production Release worked fine with ACPI. Though I DID see this: Nov 19 22:23:31 klaptopje kernel: acpi0: on motherboard Nov 19 22:23:31 klaptopje kernel: ACPI-1303: *** Error: Method execution failed [\_SB_.PCI0.ISA_.SIRA._STA] (Node 0xc14be080), AE _AML_NO_RETURN_VALUE Nov 19 22:23:31 klaptopje kernel: ACPI-0239: *** Error: Method execution failed [\_SB_.PCI0.ISA_.SIRA._STA] (Node 0xc14be080), AE _AML_NO_RETURN_VALUE Nov 19 22:23:31 klaptopje kernel: acpi0: Power Button (fixed) Nov 19 22:23:31 klaptopje kernel: acpi_ec0: port 0x66,0x62 on acpi0 Nov 19 22:23:31 klaptopje kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Nov 19 22:23:31 klaptopje kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Nov 19 22:23:31 klaptopje kernel: cpu0: on acpi0 Nov 19 22:23:31 klaptopje kernel: acpi_tz0: on acpi0 Now, with 5.3-Stable it hangs with ACPI. I posted 3 boot logs at: http://www.xs4all.nl/~sandersm/ boot-vhalt is a verbose log till the system halts boothalt is a normal log till the system halts boot is a normal when I boot without acpi. Only this way the system is usable. I also added: acpidump -t -d > klaptopje.asl hint.apic.0.disabled="1" did not help, still hangs the system. I can not get any more info, ctrl+alt+esc does not respond. uname -a FreeBSD klaptopje.lan 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Nov 20 03:53:30 UTC 2004 root@klaptopje.lan:/usr/obj/usr/src/sys/GENERIC i386 My laptop is packard beel easynote+, latest bios is installed. Let me know if someone is interested in further investigating this, I am happy to help. Regards, Maarten From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 22 13:39:28 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D6F16A4CE for ; Mon, 22 Nov 2004 13:39:28 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B0443D76 for ; Mon, 22 Nov 2004 13:39:28 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30243 invoked from network); 22 Nov 2004 13:39:28 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 22 Nov 2004 13:39:27 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iAMDdOla027124; Mon, 22 Nov 2004 08:39:24 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <20041119225850.GA49744@ip.net.ua> References: <200411111737.00537.jhb@FreeBSD.org> <20041118001947.GA53060@ip.net.ua> <20041118084627.GA72018@ip.net.ua> <200411191559.46209.jhb@FreeBSD.org> <20041119225850.GA49744@ip.net.ua> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Mon, 22 Nov 2004 08:39:16 -0500 To: Ruslan Ermilov X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: New ACPI PCI Link Routing code X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 13:39:28 -0000 On Nov 19, 2004, at 5:58 PM, Ruslan Ermilov wrote: > On Fri, Nov 19, 2004 at 03:59:46PM -0500, John Baldwin wrote: >> On Thursday 18 November 2004 03:46 am, Ruslan Ermilov wrote: >>> On Thu, Nov 18, 2004 at 02:19:47AM +0200, Ruslan Ermilov wrote: >>>> On Wed, Nov 17, 2004 at 05:44:53PM -0500, John Baldwin wrote: >>>> [...] >>>> >>>>> Erm, unless I've got a logic bug I don't run the KASSERT() for zero >>>>> interrupts. Oh darn, I left a bogus KASSERT() in in the function >>>>> that >>>>> does the actual routing. The assertion's on lines 497 and 511 can >>>>> be >>>>> dropped. I'll update the patch in a second. >>>> >>>> With an updated patch, I no longer get panic on boot, and there >>>> are no more interrupt storms, but the latter is probably at the >>>> cost of old bug re-introduced. My dc(4) PCCard doesn't get a >>>> correct IRQ, "dc0: watchdog timeout". >>> >>> I've put a verbose boot output here, as requested: >>> >>> http://people.freebsd.org/~ru/dmesg.boot >> >> Looks like it hung everything off of IRQ 9 since the BIOS didn't >> preset any >> device IRQs. What was the behavior prior to this patch? >> > http://people.freebsd.org/~ru/dmesg.boot2 > > The system is dead slow due to interrupt storm in IRQ 10, > but at least dc(4) works. > > # vmstat -i > interrupt total rate > irq0: clk 353566 993 > irq1: atkbd0 1134 3 > irq6: fdc0 22 0 > irq8: rtc 45394 127 > irq9: acpi0 648 1 > irq10: cbb1 dc0 28202293 79219 > irq11: cbb0 csa0 689545 1936 > irq12: psm0 1161 3 > irq13: npx0 1 0 > irq14: ata0 1939 5 > irq15: ata1 52 0 > Total 29295755 82291 Try setting 'hw.pci.link.LNKA.irq=11' in the loader with the patch and see if that helps dc(4) to work better. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 22 13:46:01 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDA4016A4CE for ; Mon, 22 Nov 2004 13:46:00 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8608D43D5D for ; Mon, 22 Nov 2004 13:46:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 27822 invoked from network); 22 Nov 2004 13:46:00 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 22 Nov 2004 13:45:59 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iAMDjus5027202; Mon, 22 Nov 2004 08:45:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <20041121001541.B89105D04@ptavv.es.net> References: <20041121001541.B89105D04@ptavv.es.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Mon, 22 Nov 2004 08:45:56 -0500 To: "Kevin Oberman" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 13:46:01 -0000 On Nov 20, 2004, at 7:15 PM, Kevin Oberman wrote: >> From: John Baldwin >> Date: Thu, 4 Nov 2004 17:30:04 -0500 >> >> On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: >>>> From: John Baldwin >>>> Date: Mon, 1 Nov 2004 17:48:25 -0500 >>>> >>>> On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: >>>>> Ok, well, it seems your BIOS is too busted for non-ACPI to work >>>>> out of >>>>> the box, you can try setting a hint to force the link for your >>>>> sound >>>>> card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or >>>>> maybe 'hw.pci.link.0x04.irq' if that doesn't work. >>>> >>>> Actually, the $PIR code won't let you use an invalid IRQ currently, >>>> but >>>> this patch lets it do so. I'm curious if you could try booting >>>> with this >>>> patch with ACPI disabled and using an appropriate tunable (such as >>>> 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them >>>> routed. If this does work, I'd like to try another patch as well >>>> that >>>> would help it to work out-of-the-box for the non-ACPI case. Thanks. >>> >>> John, >>> >>> I have not forgotten this, but remote testing when re-boots are >>> required >>> is a bit difficult. My wife helped me a bit yesterday, but she is a >>> Solaris type and I need to step her through things command by >>> command, >>> so it's a bit tedious. >> >> That's ok, take your time, this isn't super critical. > > O.K. I tried the loadable (hw.pci.link.0x4.irq="6"), but it still did > not work. I got the expected message: > $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 > but still no interrupts from the network card. Well, the patch doesn't fix that message, but it should let the override you add from the loader work. If your system does end up working ok I'll come up with another patch that will trust what your BIOS says over what the $PIR says. > Both the network card and the sound card claim to be using the > specified > IRQ (I tried both 6 and 10): > pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on > pci0 > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem > 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 > but 'vmstat -i' did not list IRQ6 as being in use. Well, if the device gets the IRQ, then that means the patch worked. :) Does the sound card actually work now? Note that IRQ6 won't show up in vmstat -i until the device actually interrupts. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 22 16:08:00 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E00D16A4CE; Mon, 22 Nov 2004 16:08:00 +0000 (GMT) Received: from srvdmz13.oekb.co.at (srvdmz13.oekb.co.at [143.245.5.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA51943D2D; Mon, 22 Nov 2004 16:07:58 +0000 (GMT) (envelope-from Ewald.Jenisch@oekb.at) Received: from Unknown [143.245.2.191] by srvdmz13.oekb.co.at - SurfControl E-mail Filter (4.7); Mon, 22 Nov 2004 17:07:57 +0100 Received: from athena.oekb.co.at ([143.245.83.20]) by MAIL01.oekb.co.at with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Nov 2004 17:07:56 +0100 Received: from athena.oekb.co.at (athena.oekb.co.at [127.0.0.1]) by athena.oekb.co.at (8.12.10/8.12.10) with ESMTP id iAMG83LJ017726; Mon, 22 Nov 2004 17:08:03 +0100 Received: (from ej@localhost) by athena.oekb.co.at (8.12.10/8.12.10/Submit) id iAMG83iv017725; Mon, 22 Nov 2004 17:08:03 +0100 Message-ID: <20041122160803.GA16224@athena.oekb.co.at> From: Ewald Jenisch To: freebsd-questions@freebsd.org Date: Mon, 22 Nov 2004 17:08:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OriginalArrivalTime: 22 Nov 2004 16:07:56.0339 (UTC) FILETIME=[6DCE9030:01C4D0AD] User-Agent: Mutt/1.4.1i cc: freebsd-acpi@freebsd.org Subject: Machine refuses to boot with ACPI enabled by default X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2004 16:08:00 -0000 Hi, I've got a strange problem wrt. ACPI on one of my boxes under FreeBSD 5.3: The box comes up with ACPI *disabled* by default. Only by manually selecting the menu option that says "Boot with ACPI enabled" can I make the box run ACPI which is kinda annoying when e.g. I remotely reboot the box - after the reboot it comes up without ACPI and as a consequence SMP turned off. To cross check that it's not a config issue I've "diffed" the files in /boot between the machine in question and another one that runs with ACPI enabled by default - absolutely no differences. One box (different hardware) runs with ACPI, this one runs with ACPI disabled by default. So my questions are: 1) How can I make this box boot with ACPI enabled by default? 2) Why does this box come up without ACPI by default after all? Here are the HW/SW specs of the machine in question: HP Evo d530 with latest (2.43) Bios FreeBSD 5.3 running the latest kernel as of Friday 19, 2004. I've included the output of "acpidump -t" for the machine in question below - once when it runs without ACPI (default), the other output with ACPI active (i.e. when manually selecting ACPI from the boot menu) Thanks much in advance for any help, -ewald ------------------------------ < Cut here > ------------------------------ acpidump done when box came up with ACPI disabled (default) # acpidump -t /* RSD PTR: OEM=COMPAQ, ACPI_Rev=1.0x (0) RSDT=0x000e5640, cksum=124 */ /* RSDT: Length=120, Revision=1, Checksum=240, OEMID=COMPAQ, OEM Table ID=CPQ0064, OEM Revision=0x20040810, Creator ID=, Creator Revision=0x0 Entries={ 0x000e56f8, 0x000e6585, 0x000e6c0a, 0x000e7156, 0x000e7348, 0x000e7676, 0x000e7bb5, 0x000e7d1c, 0x000e576c, 0x000e9b2c, 0x000e57d4, 0x000e8a22, 0x000e8b89, 0x000e8c66, 0x000e9200, 0x000e93b5, 0x000e8daa, 0x000e956f, 0x000e9729, 0x000e98e3, 0x000e9d30 } */ /* FACP: Length=116, Revision=1, Checksum=242, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 FACS=0xe5600, DSDT=0xe5808 INT_MODEL=APIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0x8a, ACPI_DISABLE=0x8b, S4BIOS_REQ=0x0 PSTATE_CNT=0x0 PM1a_EVT_BLK=0xf800-0xf803 PM1a_CNT_BLK=0xf804-0xf805 PM1b_CNT_BLK=0x460-0x461 PM_TMR_BLK=0xf808-0xf80b GPE0_BLK=0xf828-0xf82f P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us FLUSH_SIZE=0, FLUSH_STRIDE=32 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=13, MON_ALRM=0, CENTURY=50 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} */ /* FACS: Length=64, HwSig=0x00000000, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=3453, Revision=1, Checksum=214, OEMID=COMPAQ, OEM Table ID=DSDT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1669, Revision=1, Checksum=63, OEMID=COMPAQ, OEM Table ID=PROJECT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1356, Revision=1, Checksum=137, OEMID=COMPAQ, OEM Table ID=CORE_PNP, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=498, Revision=1, Checksum=13, OEMID=COMPAQ, OEM Table ID=CORE_UTL, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=814, Revision=1, Checksum=238, OEMID=COMPAQ, OEM Table ID=VILLTBL1, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1343, Revision=1, Checksum=108, OEMID=COMPAQ, OEM Table ID=LGCYLITE, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=359, Revision=1, Checksum=244, OEMID=COMPAQ, OEM Table ID=UART2, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=334, Revision=1, Checksum=109, OEMID=COMPAQ, OEM Table ID=FLOPPY, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* APIC: Length=104, Revision=1, Checksum=100, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=2 Flags={ENABLED} APIC ID=1 Type=IO APIC APIC ID=1 INT BASE=0 ADDR=0x00000000fec00000 Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=conforming, Trigger=conforming} Type=INT Override BUS=0 IRQ=9 INTR=9 Flags={Polarity=active-hi, Trigger=level} Type=Local NMI ACPI CPU=1 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} Type=Local NMI ACPI CPU=2 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} */ /* SSDT: Length=178, Revision=1, Checksum=227, OEMID=COMPAQ, OEM Table ID=APIC, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* ASF!: Length=52, Revision=16, Checksum=203, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 */ /* SSDT: Length=359, Revision=1, Checksum=186, OEMID=COMPAQ, OEM Table ID=S3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=221, Revision=1, Checksum=42, OEMID=COMPAQ, OEM Table ID=CORE_S3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=324, Revision=1, Checksum=12, OEMID=COMPAQ, OEM Table ID=PIDETM, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=437, Revision=1, Checksum=87, OEMID=COMPAQ, OEM Table ID=GTF0, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=2, OEMID=COMPAQ, OEM Table ID=GTF1, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=341, Revision=1, Checksum=104, OEMID=COMPAQ, OEM Table ID=SIDETM, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=134, OEMID=COMPAQ, OEM Table ID=GTF2, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=243, OEMID=COMPAQ, OEM Table ID=GTF3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=240, Revision=1, Checksum=93, OEMID=COMPAQ, OEM Table ID=L08, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=120, Revision=1, Checksum=185, OEMID=COMPAQ, OEM Table ID=FINIS, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ # ------------------------------ < Cut here > ------------------------------ acpidump done when box runs with ACPI after manually selecting "boot with ACPI enabled" # acpidump -t /* RSD PTR: OEM=COMPAQ, ACPI_Rev=1.0x (0) RSDT=0x000e5640, cksum=124 */ /* RSDT: Length=120, Revision=1, Checksum=240, OEMID=COMPAQ, OEM Table ID=CPQ0064, OEM Revision=0x20040810, Creator ID=, Creator Revision=0x0 Entries={ 0x000e56f8, 0x000e6585, 0x000e6c0a, 0x000e7156, 0x000e7348, 0x000e7676, 0x000e7bb5, 0x000e7d1c, 0x000e576c, 0x000e9b2c, 0x000e57d4, 0x000e8a22, 0x000e8b89, 0x000e8c66, 0x000e9200, 0x000e93b5, 0x000e8daa, 0x000e956f, 0x000e9729, 0x000e98e3, 0x000e9d30 } */ /* FACP: Length=116, Revision=1, Checksum=242, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 FACS=0xe5600, DSDT=0xe5808 INT_MODEL=APIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0x8a, ACPI_DISABLE=0x8b, S4BIOS_REQ=0x0 PSTATE_CNT=0x0 PM1a_EVT_BLK=0xf800-0xf803 PM1a_CNT_BLK=0xf804-0xf805 PM1b_CNT_BLK=0x460-0x461 PM_TMR_BLK=0xf808-0xf80b GPE0_BLK=0xf828-0xf82f P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us FLUSH_SIZE=0, FLUSH_STRIDE=32 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=13, MON_ALRM=0, CENTURY=50 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} */ /* FACS: Length=64, HwSig=0x00000000, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=3453, Revision=1, Checksum=214, OEMID=COMPAQ, OEM Table ID=DSDT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1669, Revision=1, Checksum=63, OEMID=COMPAQ, OEM Table ID=PROJECT, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1356, Revision=1, Checksum=137, OEMID=COMPAQ, OEM Table ID=CORE_PNP, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=498, Revision=1, Checksum=13, OEMID=COMPAQ, OEM Table ID=CORE_UTL, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=814, Revision=1, Checksum=238, OEMID=COMPAQ, OEM Table ID=VILLTBL1, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=1343, Revision=1, Checksum=108, OEMID=COMPAQ, OEM Table ID=LGCYLITE, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=359, Revision=1, Checksum=244, OEMID=COMPAQ, OEM Table ID=UART2, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=334, Revision=1, Checksum=109, OEMID=COMPAQ, OEM Table ID=FLOPPY, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* APIC: Length=104, Revision=1, Checksum=100, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=2 Flags={ENABLED} APIC ID=1 Type=IO APIC APIC ID=1 INT BASE=0 ADDR=0x00000000fec00000 Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=conforming, Trigger=conforming} Type=INT Override BUS=0 IRQ=9 INTR=9 Flags={Polarity=active-hi, Trigger=level} Type=Local NMI ACPI CPU=1 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} Type=Local NMI ACPI CPU=2 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} */ /* SSDT: Length=178, Revision=1, Checksum=227, OEMID=COMPAQ, OEM Table ID=APIC, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* ASF!: Length=52, Revision=16, Checksum=203, OEMID=COMPAQ, OEM Table ID=SPRINGD, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 */ /* SSDT: Length=359, Revision=1, Checksum=186, OEMID=COMPAQ, OEM Table ID=S3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=221, Revision=1, Checksum=42, OEMID=COMPAQ, OEM Table ID=CORE_S3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=324, Revision=1, Checksum=12, OEMID=COMPAQ, OEM Table ID=PIDETM, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=437, Revision=1, Checksum=87, OEMID=COMPAQ, OEM Table ID=GTF0, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=2, OEMID=COMPAQ, OEM Table ID=GTF1, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=341, Revision=1, Checksum=104, OEMID=COMPAQ, OEM Table ID=SIDETM, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=134, OEMID=COMPAQ, OEM Table ID=GTF2, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=442, Revision=1, Checksum=243, OEMID=COMPAQ, OEM Table ID=GTF3, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=240, Revision=1, Checksum=93, OEMID=COMPAQ, OEM Table ID=L08, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ /* SSDT: Length=120, Revision=1, Checksum=185, OEMID=COMPAQ, OEM Table ID=FINIS, OEM Revision=0x1, Creator ID=MSFT, Creator Revision=0x100000e */ # From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 01:36:55 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 602B616A4CF for ; Wed, 24 Nov 2004 01:36:55 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08CBC43D45 for ; Wed, 24 Nov 2004 01:36:55 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iAO1apC4012998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2004 17:36:52 -0800 Message-ID: <41A3E5B0.9070104@root.org> Date: Tue, 23 Nov 2004 17:36:48 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin References: <20041119112020.GA12853@daedalus.desk.pl> In-Reply-To: <20041119112020.GA12853@daedalus.desk.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: FBSD5.3 Compaq AP400 cannot warm-reboot (as in kern/27834) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 01:36:55 -0000 Marcin wrote: > Hello FreeBSD users! > > I have posted this problem to freebsd-questions, but then figured it was not actually the best place to send it. > > I'm experiencing the same problem described in http://www.freebsd.org/cgi/query-pr.cgi?pr=27834 but the fix included doesn't actually fix the problem. > > The system is FreeBSD 5.3 with GENERIC kernel on dual Compaq AP400 (Professional workstation) (dmesg/mptables below). When i reboot the system shutdowns properly (prints Rebooting...) but then just hangs with no activity (screen blank, disk diodes dead,etc). I have to push power button two times to reboot it, which is impossible with remote administration. > > This is the case with acpi.ko not loaded or with acpi.ko loaded but APIC disabled with hints.acpi.0.disabled. > > When i want to load acpi.ko wit APIC enabled i get a panic at system boottime with following message: > > "ACPI disabled by blacklist. Contact your BIOS vendor." > (from sys/dev/acpica/acpi.c acpi_Startup returning AE_ERROR) > > called by: > MADT: ACPI Startup failed with > ACPI disabled by blacklist. Contact your BIOS vendor. > Try disabling either ACPI or apic support. > panic("Using MADT but ACPI doesn't work"); > > (from sys/i386/acpica/madt.c madt_setup_io()) > > (i'm writing these from memory, i didn't have serial console to catch the exact message. If it's needed, i'll provide the exact hand written version) I did some discussion with the author of MADT and apparently the panic is necessary. You should disable acpi early with: hint.acpi.0.disabled="1" in loader.conf. Your system is older and should work with acpi disabled just fine. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 07:26:10 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C4F16A4CE for ; Wed, 24 Nov 2004 07:26:10 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5DAE43D5C for ; Wed, 24 Nov 2004 07:26:09 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAO7Q9p8019372; Wed, 24 Nov 2004 02:26:11 -0500 Message-ID: <41A43787.7070809@root.org> Date: Tue, 23 Nov 2004 23:25:59 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <419EF7AD.8050007@root.org> <20041121.081521.102766341.imp@bsdimp.com> In-Reply-To: <20041121.081521.102766341.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 07:26:10 -0000 M. Warner Losh wrote: > In message: <419EF7AD.8050007@root.org> > Nate Lawson writes: > : cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff > : cbb_power: 0V > : cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff > : cbb_power: 0V > > This looks like a problem to me. > > Warner I did a suspend with dhclient active and an an0 card present and got this: cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff cbb_power: 0V cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff cbb_power: 0V fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: DMA timeout fxp0: SCB timeout: 0xff 0xff 0xff 0xffff fxp0: SCB timeout: 0xff 0xff 0xff 0xffff Note that the policy is to set all PCI and ACPI devices to D3 when suspending unless an _SxD method says to use a different power state. fxp0 isn't present in the ACPI namespace but both cardbus ports are and both have _S3D methods that say to use D3 for S3! So this is not an error unless it's in cbb needing to do more before I power it down. I don't get any of the above messages on suspend without my patch. Suggestions? What does the "bad Vcc request" message mean? -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 07:29:27 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C031A16A4CE for ; Wed, 24 Nov 2004 07:29:27 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F37943D2F for ; Wed, 24 Nov 2004 07:29:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAO7TTp8022296; Wed, 24 Nov 2004 02:29:29 -0500 Message-ID: <41A4384F.1070003@root.org> Date: Tue, 23 Nov 2004 23:29:19 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <419EF7AD.8050007@root.org> <20041121.082812.116352579.imp@bsdimp.com> In-Reply-To: <20041121.082812.116352579.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 07:29:27 -0000 M. Warner Losh wrote: > In message: <419EF7AD.8050007@root.org> > Nate Lawson writes: > : The attached patch implements setting power states for ACPI (i.e. ISA) > : and PCI devices in the suspend/resume path. This may help with some > : problems; it's quite likely it may introduce problems. That's why I'd > : like it tested. If you have a system that suspends/resumes ok or that > : fails, please try it. The likely failure case is a hang in suspend or > : resume or a device that doesn't work afterwords. It's pretty > : heavy-handed, only avoiding changing power for serial ports since those > : are known to cause a hang (which can possibly be fixed by making > : sio/uart more aware of power states.) I suspect devices like PCI > : bridges may have problems with power changes. > : > : If you have problems, please let me know the info it prints before the > : hang so I can figure out what the problem device is. > > I suspect that we'll need finer grain control over the APM case. For > APM Bioses, the OS isn't supposed to put devices into lower power > states. The APM BIOS generally does this and restores things on > resume. APM is somewhat more limited in what it can do, so this makes > sense. Right, I agree. I've simply moved setting the power state under the acpi-only case to handle apm. > /* > - * Save the pci configuration space for each child. We don't need > - * to do this, unless the BIOS suspend code powers down the bus and > - * the devices on the bus. > + * Save the PCI configuration space for each child and set the > + * device in the appropriate power state for this sleep state. > */ > > So if APM implemented the ACPI_PWR_FOR_SLEEP interface, we'd be set. > However, there's at leas two problems with this. One is that we don't > have a way to get the 'power management' device generically (witness > the hacks to get acpi in generic pci code). Second, we don't have a > generic power interface, so having APM implement ACPI_ named methods > seems a little unsatisfying at best. I'm not sure what powermacs do > for their PM stuff, but I'm pretty sure it isn't acpi. The OS should not be setting Dx states on devices if running under APM mode. Currently, we only have 2 power management systems, apm and acpi. I don't know the PowerPC way but suspect it's largely handled by OpenFirmware, which makes it behave similar to APM, and fits nicely with the !acpi case there. Nothing I'm doing rules out a more general solution once someone implements PowerPC PowerMANAGEMENT. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 07:30:33 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0B4C16A4CE for ; Wed, 24 Nov 2004 07:30:33 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ECD643D48 for ; Wed, 24 Nov 2004 07:30:33 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAO7UZp8023264; Wed, 24 Nov 2004 02:30:35 -0500 Message-ID: <41A43892.4020005@root.org> Date: Tue, 23 Nov 2004 23:30:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <419EF7AD.8050007@root.org> <20041121.081521.102766341.imp@bsdimp.com> <41A43787.7070809@root.org> In-Reply-To: <41A43787.7070809@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 07:30:34 -0000 Nate Lawson wrote: > M. Warner Losh wrote: > >> In message: <419EF7AD.8050007@root.org> >> Nate Lawson writes: >> : cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff >> : cbb_power: 0V >> : cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff >> : cbb_power: 0V >> >> This looks like a problem to me. >> >> Warner > > > I did a suspend with dhclient active and an an0 card present and got this: > > cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff > cbb_power: 0V > cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff > cbb_power: 0V > fxp0: SCB timeout: 0xff 0xff 0xff 0xffff > fxp0: SCB timeout: 0xff 0xff 0xff 0xffff > fxp0: SCB timeout: 0xff 0xff 0xff 0xffff > fxp0: DMA timeout > > Suggestions? What does the "bad Vcc request" message mean? I forgot to mention that even with those messages, my an0 and onboard fxp0 both work fine after resume. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 07:42:35 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABFC116A4CE for ; Wed, 24 Nov 2004 07:42:35 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BC443D46 for ; Wed, 24 Nov 2004 07:42:35 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAO7gbp8001022 for ; Wed, 24 Nov 2004 02:42:37 -0500 Message-ID: <41A43B69.60901@root.org> Date: Tue, 23 Nov 2004 23:42:33 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@FreeBSD.org References: <20041121233202.8AEB95D04@ptavv.es.net> In-Reply-To: <20041121233202.8AEB95D04@ptavv.es.net> Content-Type: multipart/mixed; boundary="------------000103000906030200070407" Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 07:42:35 -0000 This is a multi-part message in MIME format. --------------000103000906030200070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nate Lawson wrote: >>Date: Fri, 19 Nov 2004 23:52:13 -0800 >>From: Nate Lawson >>The attached patch implements setting power states for ACPI (i.e. ISA) >>and PCI devices in the suspend/resume path. This may help with some >>problems; it's quite likely it may introduce problems. That's why I'd >>like it tested. If you have a system that suspends/resumes ok or that >>fails, please try it. The likely failure case is a hang in suspend or >>resume or a device that doesn't work afterwords. It's pretty >>heavy-handed, only avoiding changing power for serial ports since those >>are known to cause a hang (which can possibly be fixed by making >>sio/uart more aware of power states.) I suspect devices like PCI >>bridges may have problems with power changes. >> >>If you have problems, please let me know the info it prints before the >>hang so I can figure out what the problem device is. Ok, here's another cut of the patch. It should fix the APM case (by not tweaking power states for it) among other things. It has a tunable (defaulting to "on" or 1) where you can turn off the acpi part of things to see if that helps/hurts: hw.acpi.sleep_power -Nate --------------000103000906030200070407 Content-Type: text/plain; name="acpi_pwr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_pwr.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.193 diff -u -r1.193 acpi.c --- sys/dev/acpica/acpi.c 13 Oct 2004 07:29:29 -0000 1.193 +++ sys/dev/acpica/acpi.c 24 Nov 2004 07:35:54 -0000 @@ -59,6 +59,10 @@ #include #include +#include "pci_if.h" +#include +#include + MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); /* Hooks for the ACPI CA debugging infrastructure */ @@ -87,10 +91,13 @@ static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static int acpi_suspend(device_t dev); +static int acpi_resume(device_t dev); static int acpi_shutdown(device_t dev); static device_t acpi_add_child(device_t bus, int order, const char *name, int unit); static int acpi_print_child(device_t bus, device_t child); +static void acpi_probe_nomatch(device_t bus, device_t child); static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_write_ivar(device_t dev, device_t child, int index, @@ -110,10 +117,14 @@ static ACPI_STATUS acpi_device_eval_obj(device_t bus, device_t dev, ACPI_STRING pathname, ACPI_OBJECT_LIST *parameters, ACPI_BUFFER *ret); +static int acpi_device_pwr_for_sleep(device_t bus, device_t dev, + int *dstate); static ACPI_STATUS acpi_device_scan_cb(ACPI_HANDLE h, UINT32 level, void *context, void **retval); static ACPI_STATUS acpi_device_scan_children(device_t bus, device_t dev, int max_depth, acpi_scan_cb_t user_fn, void *arg); +static int acpi_set_powerstate_method(device_t bus, device_t child, + int state); static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); @@ -145,12 +156,13 @@ DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_shutdown, acpi_shutdown), DEVMETHOD(device_detach, bus_generic_detach), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, acpi_suspend), + DEVMETHOD(device_resume, acpi_resume), /* Bus interface */ DEVMETHOD(bus_add_child, acpi_add_child), DEVMETHOD(bus_print_child, acpi_print_child), + DEVMETHOD(bus_probe_nomatch, acpi_probe_nomatch), DEVMETHOD(bus_read_ivar, acpi_read_ivar), DEVMETHOD(bus_write_ivar, acpi_write_ivar), DEVMETHOD(bus_get_resource_list, acpi_get_rlist), @@ -169,8 +181,12 @@ /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), DEVMETHOD(acpi_evaluate_object, acpi_device_eval_obj), + DEVMETHOD(acpi_pwr_for_sleep, acpi_device_pwr_for_sleep), DEVMETHOD(acpi_scan_children, acpi_device_scan_children), + /* PCI emulation */ + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), + /* ISA emulation */ DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), @@ -212,6 +228,10 @@ static int acpi_serialize_methods; TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); +/* Power devices off and on in suspend and resume. */ +static int acpi_pwr_sleep = 1; +TUNABLE_INT("hw.acpi.sleep_power", &acpi_pwr_sleep); + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -570,6 +590,72 @@ } static int +acpi_suspend(device_t dev) +{ + struct acpi_softc *sc; + device_t child, *devlist; + int error, i, numdevs, pstate; + + /* First give child devices a chance to suspend. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Now, set them into the appropriate power state, usually D3. If the + * device has an _SxD method for the next sleep state, use that power + * state instead. + */ + sc = device_get_softc(dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + /* If the device is not attached, we've powered it down elsewhere. */ + child = devlist[i]; + if (!device_is_attached(child)) + continue; + + /* + * Default to D3 for all sleep states. The _SxD method is optional + * so set the powerstate even if it's absent. + */ + pstate = PCI_POWERSTATE_D3; + error = acpi_device_pwr_for_sleep(device_get_parent(child), + child, &pstate); + if ((error == 0 || error == ESRCH) && acpi_pwr_sleep) + pci_set_powerstate(child, pstate); + } + free(devlist, M_TEMP); + error = 0; + + return (error); +} + +static int +acpi_resume(device_t dev) +{ + ACPI_HANDLE handle; + int i, numdevs; + device_t child, *devlist; + + /* + * Put all devices in D0 before resuming them. Call _S0D on each one + * since some systems expect this. + */ + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + handle = acpi_get_handle(child); + if (handle) + AcpiEvaluateObject(handle, "_S0D", NULL, NULL); + if (device_is_attached(child) && acpi_pwr_sleep) + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + free(devlist, M_TEMP); + + return (bus_generic_resume(dev)); +} + +static int acpi_shutdown(device_t dev) { @@ -624,6 +710,23 @@ return (retval); } +static void +acpi_probe_nomatch(device_t bus, device_t child) +{ + + /* + * If this device is an ACPI child but no one claimed it, attempt + * to power it off. We'll power it back up when a driver is added. + * + * XXX Disabled for now since many necessary devices (like fdc and + * ATA) don't claim the devices we created for them but still expect + * them to be powered up. + */ +#if 0 + pci_set_powerstate(child, PCI_POWERSTATE_D3); +#endif +} + /* Location hint for devctl(8) */ static int acpi_child_location_str_method(device_t cbdev, device_t child, char *buf, @@ -1064,6 +1167,57 @@ return (AcpiEvaluateObject(h, pathname, parameters, ret)); } +static int +acpi_device_pwr_for_sleep(device_t bus, device_t dev, int *dstate) +{ + struct acpi_softc *sc; + ACPI_HANDLE handle; + ACPI_STATUS status; + char sxd[8]; + int error; + + sc = device_get_softc(bus); + handle = acpi_get_handle(dev); + + /* + * XXX If we find these devices, don't try to power them down. + * The serial and IRDA ports on my T23 hang the system when + * set to D3 and it appears that such legacy devices may + * need special handling in their drivers. + */ + if (handle == NULL || + acpi_MatchHid(handle, "PNP0500") || + acpi_MatchHid(handle, "PNP0501") || + acpi_MatchHid(handle, "PNP0502") || + acpi_MatchHid(handle, "PNP0510") || + acpi_MatchHid(handle, "PNP0511")) + return (ENXIO); + + /* + * Override next state with the value from _SxD, if present. If no + * dstate argument was provided, don't fetch the return value. + */ + snprintf(sxd, sizeof(sxd), "_S%dD", sc->acpi_sstate); + if (dstate) + status = acpi_GetInteger(handle, sxd, dstate); + else + status = AcpiEvaluateObject(handle, sxd, NULL, NULL); + + switch (status) { + case AE_OK: + error = 0; + break; + case AE_NOT_FOUND: + error = ESRCH; + break; + default: + error = ENXIO; + break; + } + + return (error); +} + /* Callback arg for our implementation of walking the namespace. */ struct acpi_device_scan_ctx { acpi_scan_cb_t user_fn; @@ -1138,6 +1292,34 @@ acpi_device_scan_cb, &ctx, NULL)); } +/* + * Even though ACPI devices are not PCI, we use the PCI approach for setting + * device power states since it's close enough to ACPI. + */ +static int +acpi_set_powerstate_method(device_t bus, device_t child, int state) +{ + ACPI_HANDLE h; + ACPI_STATUS status; + int error; + + error = 0; + h = acpi_get_handle(child); + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) + return (EINVAL); + if (h == NULL) + return (0); + + /* Ignore errors if the power methods aren't present. */ + status = acpi_pwr_switch_consumer(h, state); + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND + && status != AE_BAD_PARAMETER) + device_printf(bus, "failed to set ACPI power state D%d on %s: %s\n", + state, acpi_name(h), AcpiFormatException(status)); + + return (error); +} + static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { Index: sys/dev/acpica/acpi_if.m =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_if.m,v retrieving revision 1.2 diff -u -r1.2 acpi_if.m --- sys/dev/acpica/acpi_if.m 15 Jul 2004 16:29:08 -0000 1.2 +++ sys/dev/acpica/acpi_if.m 20 Nov 2004 03:12:35 -0000 @@ -109,6 +109,26 @@ }; # +# Get the highest power state (D0-D3) that is usable for a device when +# suspending/resuming. If a bus calls this when suspending a device, it +# must also call it when resuming. +# +# device_t bus: parent bus for the device +# +# device_t dev: check this device's appropriate power state +# +# int *dstate: if successful, contains the highest valid sleep state +# +# Returns: 0 on success, ESRCH if device has no special state, or +# some other error value. +# +METHOD int pwr_for_sleep { + device_t bus; + device_t dev; + int *dstate; +}; + +# # Rescan a subtree and optionally reattach devices to handles. Users # specify a callback that is called for each ACPI_HANDLE of type Device # that is a child of "dev". Index: sys/dev/acpica/acpi_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci.c,v retrieving revision 1.24 diff -u -r1.24 acpi_pci.c --- sys/dev/acpica/acpi_pci.c 22 Sep 2004 15:46:16 -0000 1.24 +++ sys/dev/acpica/acpi_pci.c 22 Nov 2004 17:54:25 -0000 @@ -59,6 +59,12 @@ ACPI_SERIAL_DECL(pci_powerstate, "ACPI PCI power methods"); +/* Be sure that ACPI and PCI power states are equivalent. */ +CTASSERT(ACPI_STATE_D0 == PCI_POWERSTATE_D0); +CTASSERT(ACPI_STATE_D1 == PCI_POWERSTATE_D1); +CTASSERT(ACPI_STATE_D2 == PCI_POWERSTATE_D2); +CTASSERT(ACPI_STATE_D3 == PCI_POWERSTATE_D3); + static int acpi_pci_attach(device_t dev); static int acpi_pci_child_location_str_method(device_t cbdev, device_t child, char *buf, size_t buflen); @@ -183,25 +189,11 @@ { ACPI_HANDLE h; ACPI_STATUS status; - int acpi_state, old_state, error; + int old_state, error; error = 0; - switch (state) { - case PCI_POWERSTATE_D0: - acpi_state = ACPI_STATE_D0; - break; - case PCI_POWERSTATE_D1: - acpi_state = ACPI_STATE_D1; - break; - case PCI_POWERSTATE_D2: - acpi_state = ACPI_STATE_D2; - break; - case PCI_POWERSTATE_D3: - acpi_state = ACPI_STATE_D3; - break; - default: + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) return (EINVAL); - } /* * We set the state using PCI Power Management outside of setting @@ -220,11 +212,11 @@ goto out; } h = acpi_get_handle(child); - status = acpi_pwr_switch_consumer(h, acpi_state); + status = acpi_pwr_switch_consumer(h, state); if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) device_printf(dev, "Failed to set ACPI power state D%d on %s: %s\n", - acpi_state, acpi_name(h), AcpiFormatException(status)); + state, acpi_name(h), AcpiFormatException(status)); if (old_state > state) error = pci_set_powerstate_method(dev, child, state); Index: sys/dev/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.268 diff -u -r1.268 pci.c --- sys/dev/pci/pci.c 10 Nov 2004 00:41:39 -0000 1.268 +++ sys/dev/pci/pci.c 22 Nov 2004 17:30:44 -0000 @@ -60,6 +60,10 @@ #include "pcib_if.h" #include "pci_if.h" +#include +#include +#include "acpi_if.h" + static uint32_t pci_mapbase(unsigned mapreg); static int pci_maptype(unsigned mapreg); static int pci_mapsize(unsigned testval); @@ -1016,22 +1020,31 @@ int pci_suspend(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int dstate, i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_save(child, dinfo, 0); + + /* + * Always set the device to D3. If ACPI suggests a different + * power state, use it instead. If ACPI is not present, the + * firmware is responsible for managing device power. + */ + if (acpi_dev != NULL) { + dstate = PCI_POWERSTATE_D3; + ACPI_PWR_FOR_SLEEP(acpi_dev, child, &dstate); + pci_set_powerstate(child, dstate); + } } free(devlist, M_TEMP); return (bus_generic_suspend(dev)); @@ -1040,18 +1053,28 @@ int pci_resume(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Restore the pci configuration space for each child. + * Set each child to D0 and restore its PCI configuration space. */ + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { + /* + * Notify ACPI we're going to D0 but ignore the result. + * If ACPI is not present, the firmware is responsible for + * managing device power. + */ child = devlist[i]; + if (acpi_dev != NULL) { + ACPI_PWR_FOR_SLEEP(acpi_dev, child, NULL); + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + + /* Now the device is powered up, restore its config space. */ dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_restore(child, dinfo); } --------------000103000906030200070407-- From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 15:03:49 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E21A616A4CE for ; Wed, 24 Nov 2004 15:03:49 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C1D43D49 for ; Wed, 24 Nov 2004 15:03:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iAOF206G053739; Wed, 24 Nov 2004 08:02:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 24 Nov 2004 08:02:40 -0700 (MST) Message-Id: <20041124.080240.60195009.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <41A43787.7070809@root.org> References: <419EF7AD.8050007@root.org> <20041121.081521.102766341.imp@bsdimp.com> <41A43787.7070809@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 15:03:50 -0000 In message: <41A43787.7070809@root.org> Nate Lawson writes: : M. Warner Losh wrote: : > In message: <419EF7AD.8050007@root.org> : > Nate Lawson writes: : > : cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : > : cbb_power: 0V : > : cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : > : cbb_power: 0V : > : > This looks like a problem to me. : > : > Warner : : I did a suspend with dhclient active and an an0 card present and got this: : : cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : cbb_power: 0V : cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff : cbb_power: 0V : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: DMA timeout : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : fxp0: SCB timeout: 0xff 0xff 0xff 0xffff : : Note that the policy is to set all PCI and ACPI devices to D3 when : suspending unless an _SxD method says to use a different power state. : fxp0 isn't present in the ACPI namespace but both cardbus ports are and : both have _S3D methods that say to use D3 for S3! So this is not an : error unless it's in cbb needing to do more before I power it down. I : don't get any of the above messages on suspend without my patch. : : Suggestions? What does the "bad Vcc request" message mean? At a guess, I'd say that we're accessing the hardware after the power state has been set to d3, likely via an interrupt. 'bad Vcc request' is just a bit that's set in the pccbb hardware. It is almost never right, especially with the status of 0xffffffff. Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 16:07:38 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647C116A4CF; Wed, 24 Nov 2004 16:07:38 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD3443D5E; Wed, 24 Nov 2004 16:07:37 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id iAOG7Yg5008289; Wed, 24 Nov 2004 16:07:34 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.13.1) with ESMTP id iAOG7Yqm057811; Wed, 24 Nov 2004 16:07:34 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.13.1/Submit) id iAOG7Yf1057810; Wed, 24 Nov 2004 16:07:34 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101312453.56574.122.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 24 Nov 2004 16:07:34 +0000 X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Subject: Memory modified after free: Most recently used by acpitask X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:07:38 -0000 Hi, Just got a panic on a 6-CURRENT (Thu Nov 18 16:36:35 GMT 2004) machine, while copying a large amount of data around. Seems to be an ACPI related reuse-after-free. As far as I can tell, 20 bytes into the acpi_task structure is (int)ta_flags within the embedded struct task, but I can't see use of this field in the ACPI code so ACPI may be a red herring. Sadly, I don't have a core dump as the machine double faulted during the attempt. Gavin # cp -Rp /usr/* /var/usr [about 10 minutes later] Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 panic: Most recently used by acpitask cpuid = 1 KDB: enter: panic [thread 100103] Stopped at kdb_enter+0x2c: leave db> tr kdb_enter(c081145f,100,c3929480,1c,c44a843c) at kdb_enter+0x2c panic(c082b121,c0a312d0,c082b0f2,c44a8420,1c) at panic+0x17f mtrash_ctor(c44a8420,20,0,502) at mtrash_ctor+0x5f uma_zalloc_arg(c1052420,0,502) at uma_zalloc_arg+0x3d8 malloc(20,c08a80c0,502,0,0) at malloc+0x6b softdep_setup_directory_add(d7583cb0,c5379348,28,0,f769f) at softdep_setup_directory_add+0x61 ufs_direnter(c5e9dac8,c58aa78c,ecc95924,ecc95c0c,0,c53e4834,ecc95c0c,ecc95924) at ufs_direnter+0x6ff ufs_makeinode(ecc95bf8,ecc95c0c,ecc95a6c,ecc95b2c,c0668f16) at ufs_makeinode+0x267 ufs_create(ecc95a70) at ufs_create+0x25 vn_open_cred(ecc95be4,ecc95ce4,16d,c3480780,4) at vn_open_cred+0x49a vn_open(ecc95be4,ecc95ce4,16d,4,c08d2040,8,c081a444,3bc) at vn_open+0x1e kern_open(c3929480,804b868,0,602,816d) at kern_open+0xd6 open(c3929480,ecc95d14,3,1015d,286) at open+0x18 syscall(804002f,2f,bfbf002f,804b89d,1) at syscall+0x128 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280c1bdf, esp = 0xbfbfeb3c, ebp = 0xbfbfeb88 --- Gavin From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 16:34:16 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3455E16A507; Wed, 24 Nov 2004 16:34:16 +0000 (GMT) Received: from r1a.corp.servercentral.net (exchange.corp.servercentral.net [66.225.247.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB7BA43D3F; Wed, 24 Nov 2004 16:34:15 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail pickup service by r1a.corp.servercentral.net with Microsoft SMTPSVC; Wed, 24 Nov 2004 10:34:05 -0600 Received: from demandindustries.net ([161.58.224.124]) by r1a.corp.servercentral.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 10:08:03 -0600 Received: from scanner.servercentral.net (scanner.servercentral.net [66.225.196.47]) by demandindustries.net (8.12.11/8.12.9) with ESMTP id iAOG82bh023840 for ; Wed, 24 Nov 2004 10:08:02 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by scanner.servercentral.net (Postfix) with ESMTP id 021F08700B0 for ; Wed, 24 Nov 2004 10:07:56 -0600 (CST) Received: from scanner.servercentral.net ([127.0.0.1]) by localhost (mb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06317-03 for ; Wed, 24 Nov 2004 10:07:51 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by scanner.servercentral.net (Postfix) with ESMTP id 8706C8700AB for ; Wed, 24 Nov 2004 10:07:51 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 7FF5057FE8; Wed, 24 Nov 2004 16:07:53 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CF0FF16A51B; Wed, 24 Nov 2004 16:07:46 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647C116A4CF; Wed, 24 Nov 2004 16:07:38 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD3443D5E; Wed, 24 Nov 2004 16:07:37 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id iAOG7Yg5008289; Wed, 24 Nov 2004 16:07:34 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.13.1) with ESMTP id iAOG7Yqm057811; Wed, 24 Nov 2004 16:07:34 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.13.1/Submit) id iAOG7Yf1057810; Wed, 24 Nov 2004 16:07:34 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101312453.56574.122.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 24 Nov 2004 16:07:34 +0000 X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Virus-Scanned: by amavis for cervercentral.net X-OriginalArrivalTime: 24 Nov 2004 16:08:03.0411 (UTC) FILETIME=[C6D92A30:01C4D23F] Subject: Memory modified after free: Most recently used by acpitask X-BeenThere: freebsd-acpi@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:34:16 -0000 Hi, Just got a panic on a 6-CURRENT (Thu Nov 18 16:36:35 GMT 2004) machine, while copying a large amount of data around. Seems to be an ACPI related reuse-after-free. As far as I can tell, 20 bytes into the acpi_task structure is (int)ta_flags within the embedded struct task, but I can't see use of this field in the ACPI code so ACPI may be a red herring. Sadly, I don't have a core dump as the machine double faulted during the attempt. Gavin # cp -Rp /usr/* /var/usr [about 10 minutes later] Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 panic: Most recently used by acpitask cpuid = 1 KDB: enter: panic [thread 100103] Stopped at kdb_enter+0x2c: leave db> tr kdb_enter(c081145f,100,c3929480,1c,c44a843c) at kdb_enter+0x2c panic(c082b121,c0a312d0,c082b0f2,c44a8420,1c) at panic+0x17f mtrash_ctor(c44a8420,20,0,502) at mtrash_ctor+0x5f uma_zalloc_arg(c1052420,0,502) at uma_zalloc_arg+0x3d8 malloc(20,c08a80c0,502,0,0) at malloc+0x6b softdep_setup_directory_add(d7583cb0,c5379348,28,0,f769f) at softdep_setup_directory_add+0x61 ufs_direnter(c5e9dac8,c58aa78c,ecc95924,ecc95c0c,0,c53e4834,ecc95c0c,ecc95924) at ufs_direnter+0x6ff ufs_makeinode(ecc95bf8,ecc95c0c,ecc95a6c,ecc95b2c,c0668f16) at ufs_makeinode+0x267 ufs_create(ecc95a70) at ufs_create+0x25 vn_open_cred(ecc95be4,ecc95ce4,16d,c3480780,4) at vn_open_cred+0x49a vn_open(ecc95be4,ecc95ce4,16d,4,c08d2040,8,c081a444,3bc) at vn_open+0x1e kern_open(c3929480,804b868,0,602,816d) at kern_open+0xd6 open(c3929480,ecc95d14,3,1015d,286) at open+0x18 syscall(804002f,2f,bfbf002f,804b89d,1) at syscall+0x128 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280c1bdf, esp = 0xbfbfeb3c, ebp = 0xbfbfeb88 --- Gavin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 16:49:08 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A05416A4CE; Wed, 24 Nov 2004 16:49:08 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 214EB43D5A; Wed, 24 Nov 2004 16:49:08 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAOGn9Hr000738; Wed, 24 Nov 2004 11:49:10 -0500 Message-ID: <41A4BB82.2010406@root.org> Date: Wed, 24 Nov 2004 08:49:06 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gavin Atkinson References: <1101312453.56574.122.camel@buffy.york.ac.uk> In-Reply-To: <1101312453.56574.122.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Memory modified after free: Most recently used by acpitask X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 16:49:08 -0000 Gavin Atkinson wrote: > Hi, > > Just got a panic on a 6-CURRENT (Thu Nov 18 16:36:35 GMT 2004) machine, > while copying a large amount of data around. > > Seems to be an ACPI related reuse-after-free. As far as I can tell, 20 > bytes into the acpi_task structure is (int)ta_flags within the embedded > struct task, but I can't see use of this field in the ACPI code so ACPI > may be a red herring. > > Sadly, I don't have a core dump as the machine double faulted during the > attempt. > > Gavin > > > # cp -Rp /usr/* /var/usr > [about 10 minutes later] > Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 > panic: Most recently used by acpitask Unfortunately, the panic message doesn't tell you who modified it since someone with a stray pointer (say, who allocated/freed it before acpi) could overwrite it and it was only detected on the next malloc. The way I've found these is to boot -d (into ddb) and type "watch 0xc44a8420". Then hit "c" to continue the boot. Dump a "tr" any time the watchpoint triggers and look for suspicious callers. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 17:33:05 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D40416A4CE for ; Wed, 24 Nov 2004 17:33:05 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29AF843D45 for ; Wed, 24 Nov 2004 17:33:05 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP id IBA74465; Wed, 24 Nov 2004 09:33:04 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3D7A15D07; Wed, 24 Nov 2004 09:33:04 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Tue, 23 Nov 2004 23:42:33 PST." <41A43B69.60901@root.org> Date: Wed, 24 Nov 2004 09:33:04 -0800 From: "Kevin Oberman" Message-Id: <20041124173304.3D7A15D07@ptavv.es.net> cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 17:33:05 -0000 Nate, I have tried the new set of ACPI power patches and they are better. Now the system almost works after resume. Only the cbb fails: cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff cbb_power: 0V tdkphy0: detached miibus1: detached dc0: detached sio4: detached cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff cbb_power: 0V cbb1: bad Vcc request. ctrl=0xffffff88, status=0xffffffff cbb_power: 0V wakeup from sleeping state (slept 00:00:11) cbb1: CardBus card activation failed Re-inserting the card simply generates another cbb1: CardBus card activation failed And, sound still runs at the raw rate (about 10% fast). I was REALLY hoping that this would fix the sound. :-( For the record, the patch did not quite install cleanly. There was an offset of one line for the last two hunks for pci.c. My source was at V1.264 and several changes have been made in HEAD since then. Probably not significant. As always, let me know if you would like me to provide more information. System IBM T30, 1.8 GHz P4m, 512 MB RAM. RELENG_5 of 11/21. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 17:49:24 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 407B616A4CE for ; Wed, 24 Nov 2004 17:49:24 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id B657243D41 for ; Wed, 24 Nov 2004 17:49:23 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])iAOHnNp8012158; Wed, 24 Nov 2004 12:49:23 -0500 Message-ID: <41A4C99E.8050507@root.org> Date: Wed, 24 Nov 2004 09:49:18 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20041124173304.3D7A15D07@ptavv.es.net> In-Reply-To: <20041124173304.3D7A15D07@ptavv.es.net> Content-Type: multipart/mixed; boundary="------------010606030407040208010108" cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 17:49:24 -0000 This is a multi-part message in MIME format. --------------010606030407040208010108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kevin Oberman wrote: > I have tried the new set of ACPI power patches and they are better. Now > the system almost works after resume. Only the cbb fails: > cbb0: bad Vcc request. ctrl=0xffffff88, status=0xffffffff > cbb_power: 0V > tdkphy0: detached Apologies, I just found what was causing this. My patch to perform suspending before powering down devices didn't get merged with this tree where I was implementing powerstates. I fixed this and unified pci/acpi power on suspend behavior under the tunable/sysctl "debug.suspend_power". Please test the attached patch. If it works well, I'll commit it as shown to get testing in -current. If it causes trouble, the default for debug.suspend_power can be set to 0. -Nate --------------010606030407040208010108 Content-Type: text/plain; name="acpi_pwr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_pwr.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.193 diff -u -r1.193 acpi.c --- sys/dev/acpica/acpi.c 13 Oct 2004 07:29:29 -0000 1.193 +++ sys/dev/acpica/acpi.c 24 Nov 2004 17:41:34 -0000 @@ -59,6 +59,10 @@ #include #include +#include "pci_if.h" +#include +#include + MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); /* Hooks for the ACPI CA debugging infrastructure */ @@ -87,10 +91,13 @@ static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static int acpi_suspend(device_t dev); +static int acpi_resume(device_t dev); static int acpi_shutdown(device_t dev); static device_t acpi_add_child(device_t bus, int order, const char *name, int unit); static int acpi_print_child(device_t bus, device_t child); +static void acpi_probe_nomatch(device_t bus, device_t child); static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_write_ivar(device_t dev, device_t child, int index, @@ -110,10 +117,14 @@ static ACPI_STATUS acpi_device_eval_obj(device_t bus, device_t dev, ACPI_STRING pathname, ACPI_OBJECT_LIST *parameters, ACPI_BUFFER *ret); +static int acpi_device_pwr_for_sleep(device_t bus, device_t dev, + int *dstate); static ACPI_STATUS acpi_device_scan_cb(ACPI_HANDLE h, UINT32 level, void *context, void **retval); static ACPI_STATUS acpi_device_scan_children(device_t bus, device_t dev, int max_depth, acpi_scan_cb_t user_fn, void *arg); +static int acpi_set_powerstate_method(device_t bus, device_t child, + int state); static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); @@ -145,12 +156,13 @@ DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_shutdown, acpi_shutdown), DEVMETHOD(device_detach, bus_generic_detach), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, acpi_suspend), + DEVMETHOD(device_resume, acpi_resume), /* Bus interface */ DEVMETHOD(bus_add_child, acpi_add_child), DEVMETHOD(bus_print_child, acpi_print_child), + DEVMETHOD(bus_probe_nomatch, acpi_probe_nomatch), DEVMETHOD(bus_read_ivar, acpi_read_ivar), DEVMETHOD(bus_write_ivar, acpi_write_ivar), DEVMETHOD(bus_get_resource_list, acpi_get_rlist), @@ -169,8 +181,12 @@ /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), DEVMETHOD(acpi_evaluate_object, acpi_device_eval_obj), + DEVMETHOD(acpi_pwr_for_sleep, acpi_device_pwr_for_sleep), DEVMETHOD(acpi_scan_children, acpi_device_scan_children), + /* PCI emulation */ + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), + /* ISA emulation */ DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), @@ -212,6 +228,9 @@ static int acpi_serialize_methods; TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); +/* Power devices off and on in suspend and resume. XXX Remove once tested. */ +extern int do_suspend_power; + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -570,6 +589,72 @@ } static int +acpi_suspend(device_t dev) +{ + struct acpi_softc *sc; + device_t child, *devlist; + int error, i, numdevs, pstate; + + /* First give child devices a chance to suspend. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Now, set them into the appropriate power state, usually D3. If the + * device has an _SxD method for the next sleep state, use that power + * state instead. + */ + sc = device_get_softc(dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + /* If the device is not attached, we've powered it down elsewhere. */ + child = devlist[i]; + if (!device_is_attached(child)) + continue; + + /* + * Default to D3 for all sleep states. The _SxD method is optional + * so set the powerstate even if it's absent. + */ + pstate = PCI_POWERSTATE_D3; + error = acpi_device_pwr_for_sleep(device_get_parent(child), + child, &pstate); + if ((error == 0 || error == ESRCH) && do_suspend_power) + pci_set_powerstate(child, pstate); + } + free(devlist, M_TEMP); + error = 0; + + return (error); +} + +static int +acpi_resume(device_t dev) +{ + ACPI_HANDLE handle; + int i, numdevs; + device_t child, *devlist; + + /* + * Put all devices in D0 before resuming them. Call _S0D on each one + * since some systems expect this. + */ + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + handle = acpi_get_handle(child); + if (handle) + AcpiEvaluateObject(handle, "_S0D", NULL, NULL); + if (device_is_attached(child) && do_suspend_power) + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + free(devlist, M_TEMP); + + return (bus_generic_resume(dev)); +} + +static int acpi_shutdown(device_t dev) { @@ -624,6 +709,23 @@ return (retval); } +static void +acpi_probe_nomatch(device_t bus, device_t child) +{ + + /* + * If this device is an ACPI child but no one claimed it, attempt + * to power it off. We'll power it back up when a driver is added. + * + * XXX Disabled for now since many necessary devices (like fdc and + * ATA) don't claim the devices we created for them but still expect + * them to be powered up. + */ +#if 0 + pci_set_powerstate(child, PCI_POWERSTATE_D3); +#endif +} + /* Location hint for devctl(8) */ static int acpi_child_location_str_method(device_t cbdev, device_t child, char *buf, @@ -1064,6 +1166,57 @@ return (AcpiEvaluateObject(h, pathname, parameters, ret)); } +static int +acpi_device_pwr_for_sleep(device_t bus, device_t dev, int *dstate) +{ + struct acpi_softc *sc; + ACPI_HANDLE handle; + ACPI_STATUS status; + char sxd[8]; + int error; + + sc = device_get_softc(bus); + handle = acpi_get_handle(dev); + + /* + * XXX If we find these devices, don't try to power them down. + * The serial and IRDA ports on my T23 hang the system when + * set to D3 and it appears that such legacy devices may + * need special handling in their drivers. + */ + if (handle == NULL || + acpi_MatchHid(handle, "PNP0500") || + acpi_MatchHid(handle, "PNP0501") || + acpi_MatchHid(handle, "PNP0502") || + acpi_MatchHid(handle, "PNP0510") || + acpi_MatchHid(handle, "PNP0511")) + return (ENXIO); + + /* + * Override next state with the value from _SxD, if present. If no + * dstate argument was provided, don't fetch the return value. + */ + snprintf(sxd, sizeof(sxd), "_S%dD", sc->acpi_sstate); + if (dstate) + status = acpi_GetInteger(handle, sxd, dstate); + else + status = AcpiEvaluateObject(handle, sxd, NULL, NULL); + + switch (status) { + case AE_OK: + error = 0; + break; + case AE_NOT_FOUND: + error = ESRCH; + break; + default: + error = ENXIO; + break; + } + + return (error); +} + /* Callback arg for our implementation of walking the namespace. */ struct acpi_device_scan_ctx { acpi_scan_cb_t user_fn; @@ -1138,6 +1291,34 @@ acpi_device_scan_cb, &ctx, NULL)); } +/* + * Even though ACPI devices are not PCI, we use the PCI approach for setting + * device power states since it's close enough to ACPI. + */ +static int +acpi_set_powerstate_method(device_t bus, device_t child, int state) +{ + ACPI_HANDLE h; + ACPI_STATUS status; + int error; + + error = 0; + h = acpi_get_handle(child); + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) + return (EINVAL); + if (h == NULL) + return (0); + + /* Ignore errors if the power methods aren't present. */ + status = acpi_pwr_switch_consumer(h, state); + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND + && status != AE_BAD_PARAMETER) + device_printf(bus, "failed to set ACPI power state D%d on %s: %s\n", + state, acpi_name(h), AcpiFormatException(status)); + + return (error); +} + static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { Index: sys/dev/acpica/acpi_if.m =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_if.m,v retrieving revision 1.2 diff -u -r1.2 acpi_if.m --- sys/dev/acpica/acpi_if.m 15 Jul 2004 16:29:08 -0000 1.2 +++ sys/dev/acpica/acpi_if.m 20 Nov 2004 03:12:35 -0000 @@ -109,6 +109,26 @@ }; # +# Get the highest power state (D0-D3) that is usable for a device when +# suspending/resuming. If a bus calls this when suspending a device, it +# must also call it when resuming. +# +# device_t bus: parent bus for the device +# +# device_t dev: check this device's appropriate power state +# +# int *dstate: if successful, contains the highest valid sleep state +# +# Returns: 0 on success, ESRCH if device has no special state, or +# some other error value. +# +METHOD int pwr_for_sleep { + device_t bus; + device_t dev; + int *dstate; +}; + +# # Rescan a subtree and optionally reattach devices to handles. Users # specify a callback that is called for each ACPI_HANDLE of type Device # that is a child of "dev". Index: sys/dev/acpica/acpi_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci.c,v retrieving revision 1.24 diff -u -r1.24 acpi_pci.c --- sys/dev/acpica/acpi_pci.c 22 Sep 2004 15:46:16 -0000 1.24 +++ sys/dev/acpica/acpi_pci.c 22 Nov 2004 17:54:25 -0000 @@ -59,6 +59,12 @@ ACPI_SERIAL_DECL(pci_powerstate, "ACPI PCI power methods"); +/* Be sure that ACPI and PCI power states are equivalent. */ +CTASSERT(ACPI_STATE_D0 == PCI_POWERSTATE_D0); +CTASSERT(ACPI_STATE_D1 == PCI_POWERSTATE_D1); +CTASSERT(ACPI_STATE_D2 == PCI_POWERSTATE_D2); +CTASSERT(ACPI_STATE_D3 == PCI_POWERSTATE_D3); + static int acpi_pci_attach(device_t dev); static int acpi_pci_child_location_str_method(device_t cbdev, device_t child, char *buf, size_t buflen); @@ -183,25 +189,11 @@ { ACPI_HANDLE h; ACPI_STATUS status; - int acpi_state, old_state, error; + int old_state, error; error = 0; - switch (state) { - case PCI_POWERSTATE_D0: - acpi_state = ACPI_STATE_D0; - break; - case PCI_POWERSTATE_D1: - acpi_state = ACPI_STATE_D1; - break; - case PCI_POWERSTATE_D2: - acpi_state = ACPI_STATE_D2; - break; - case PCI_POWERSTATE_D3: - acpi_state = ACPI_STATE_D3; - break; - default: + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) return (EINVAL); - } /* * We set the state using PCI Power Management outside of setting @@ -220,11 +212,11 @@ goto out; } h = acpi_get_handle(child); - status = acpi_pwr_switch_consumer(h, acpi_state); + status = acpi_pwr_switch_consumer(h, state); if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) device_printf(dev, "Failed to set ACPI power state D%d on %s: %s\n", - acpi_state, acpi_name(h), AcpiFormatException(status)); + state, acpi_name(h), AcpiFormatException(status)); if (old_state > state) error = pci_set_powerstate_method(dev, child, state); Index: sys/dev/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.268 diff -u -r1.268 pci.c --- sys/dev/pci/pci.c 10 Nov 2004 00:41:39 -0000 1.268 +++ sys/dev/pci/pci.c 24 Nov 2004 17:40:58 -0000 @@ -60,6 +60,10 @@ #include "pcib_if.h" #include "pci_if.h" +#include +#include +#include "acpi_if.h" + static uint32_t pci_mapbase(unsigned mapreg); static int pci_maptype(unsigned mapreg); static int pci_mapsize(unsigned testval); @@ -183,6 +187,11 @@ "Power down devices into D3 state when no driver attaches to them.\n\ Otherwise, leave the device in D0 state when no driver attaches."); +int do_suspend_power = 1; +TUNABLE_INT("debug.suspend_power", &do_suspend_power); +SYSCTL_INT(_debug, OID_AUTO, suspend_power, CTLFLAG_RW, + &do_suspend_power, 1, "Power down devices into D3 state in suspend."); + /* Find a device_t by bus/slot/function */ device_t @@ -1016,42 +1025,71 @@ int pci_suspend(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int dstate, error, i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ + acpi_dev = NULL; + if (do_suspend_power) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_save(child, dinfo, 0); } + + /* Suspend devices before potentially powering them down. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Always set the device to D3. If ACPI suggests a different + * power state, use it instead. If ACPI is not present, the + * firmware is responsible for managing device power. + */ + for (i = 0; acpi_dev && i < numdevs; i++) { + child = devlist[i]; + dstate = PCI_POWERSTATE_D3; + ACPI_PWR_FOR_SLEEP(acpi_dev, child, &dstate); + pci_set_powerstate(child, dstate); + } free(devlist, M_TEMP); - return (bus_generic_suspend(dev)); + return (0); } int pci_resume(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Restore the pci configuration space for each child. + * Set each child to D0 and restore its PCI configuration space. */ + acpi_dev = NULL; + if (do_suspend_power) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { + /* + * Notify ACPI we're going to D0 but ignore the result. + * If ACPI is not present, the firmware is responsible for + * managing device power. + */ child = devlist[i]; + if (acpi_dev) { + ACPI_PWR_FOR_SLEEP(acpi_dev, child, NULL); + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + + /* Now the device is powered up, restore its config space. */ dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_restore(child, dinfo); } --------------010606030407040208010108-- From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 18:07:48 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5602816A4CE; Wed, 24 Nov 2004 18:07:48 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B9143D2F; Wed, 24 Nov 2004 18:07:47 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id iAOI7hg5024948; Wed, 24 Nov 2004 18:07:43 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.13.1) with ESMTP id iAOI7hYC058210; Wed, 24 Nov 2004 18:07:43 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.13.1/Submit) id iAOI7hkB058209; Wed, 24 Nov 2004 18:07:43 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Nate Lawson In-Reply-To: <41A4BB82.2010406@root.org> References: <1101312453.56574.122.camel@buffy.york.ac.uk> <41A4BB82.2010406@root.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101319662.56574.141.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 24 Nov 2004 18:07:43 +0000 X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Memory modified after free: Most recently used by acpitask X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 18:07:48 -0000 On Wed, 2004-11-24 at 16:49, Nate Lawson wrote: > Gavin Atkinson wrote: > > Hi, > > > > Just got a panic on a 6-CURRENT (Thu Nov 18 16:36:35 GMT 2004) machine, > > while copying a large amount of data around. > > > > Seems to be an ACPI related reuse-after-free. As far as I can tell, 20 > > bytes into the acpi_task structure is (int)ta_flags within the embedded > > struct task, but I can't see use of this field in the ACPI code so ACPI > > may be a red herring. > > > > > > # cp -Rp /usr/* /var/usr > > [about 10 minutes later] > > Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 > > panic: Most recently used by acpitask > > Unfortunately, the panic message doesn't tell you who modified it since > someone with a stray pointer (say, who allocated/freed it before acpi) > could overwrite it and it was only detected on the next malloc. The way > I've found these is to boot -d (into ddb) and type "watch 0xc44a8420". > Then hit "c" to continue the boot. Dump a "tr" any time the watchpoint > triggers and look for suspicious callers. Sadly, I suspect it's not going to be that easy. I've just had another panic, same trigger and symptoms but different memory address. Memory modified after free 0xc50441c0(28) val=0 @ 0xc50441d4 panic: Most recently used by acpitask cpuid = 0 KDB: enter: panic [thread 100111] Stopped at kdb_enter+0x2c: leave I'll try taking the box to top-of-tree current in case it has already been fixed - however that will probably have to wait until tomorrow now as this machine cannot reboot without physical help. Surely it seems like quite a coincidence that both times it was 20 bytes into memory once owned by acpitask, though? Gavin From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 18:28:13 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC1D116A4CE; Wed, 24 Nov 2004 18:28:13 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E91343D1D; Wed, 24 Nov 2004 18:28:13 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])iAOISFHr011325; Wed, 24 Nov 2004 13:28:15 -0500 Message-ID: <41A4D2BB.7090400@root.org> Date: Wed, 24 Nov 2004 10:28:11 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gavin Atkinson References: <1101312453.56574.122.camel@buffy.york.ac.uk> <41A4BB82.2010406@root.org> <1101319662.56574.141.camel@buffy.york.ac.uk> In-Reply-To: <1101319662.56574.141.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Memory modified after free: Most recently used by acpitask X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 18:28:13 -0000 Gavin Atkinson wrote: > On Wed, 2004-11-24 at 16:49, Nate Lawson wrote: > >>Gavin Atkinson wrote: >>># cp -Rp /usr/* /var/usr >>>[about 10 minutes later] >>>Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 >>>panic: Most recently used by acpitask >> >>Unfortunately, the panic message doesn't tell you who modified it since >>someone with a stray pointer (say, who allocated/freed it before acpi) >>could overwrite it and it was only detected on the next malloc. The way >>I've found these is to boot -d (into ddb) and type "watch 0xc44a8420". >>Then hit "c" to continue the boot. Dump a "tr" any time the watchpoint >>triggers and look for suspicious callers. > > > Sadly, I suspect it's not going to be that easy. I've just had another > panic, same trigger and symptoms but different memory address. > > Memory modified after free 0xc50441c0(28) val=0 @ 0xc50441d4 > panic: Most recently used by acpitask > > cpuid = 0 > KDB: enter: panic > [thread 100111] > Stopped at kdb_enter+0x2c: leave > > I'll try taking the box to top-of-tree current in case it has already > been fixed - however that will probably have to wait until tomorrow now > as this machine cannot reboot without physical help. Surely it seems > like quite a coincidence that both times it was 20 bytes into memory > once owned by acpitask, though? The only coincidence is it's likely the same component causing this problem. acpi is probably only a victim. FYI, in August I fixed an overflow in ATA that had the same symptoms of overwriting an ACPI struct (although that doesn't mean this is caused by ATA). -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 21:50:02 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0926C16A4D0; Wed, 24 Nov 2004 21:50:02 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A336D43D45; Wed, 24 Nov 2004 21:50:01 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id 187E82602F; Wed, 24 Nov 2004 22:50:01 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A607A26020; Wed, 24 Nov 2004 22:49:57 +0100 (CET) Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id iAOLnvLE017530; Wed, 24 Nov 2004 22:49:57 +0100 Received: (nullmailer pid 1017 invoked by uid 1001); Wed, 24 Nov 2004 21:49:56 -0000 Date: Wed, 24 Nov 2004 22:49:56 +0100 From: Mark Santcroos To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Message-ID: <20041124214956.GA829@laptop.6bone.nl> References: <20041115211636.GA1540@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041115211636.GA1540@laptop.6bone.nl> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.009379 / -5.9 X-RIPE-Signature: 3b05a663b3ef164b232702a2cd660437 Subject: [PATCH] Please test: new ACPI release (20041119) import X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 21:50:02 -0000 Here [1] is a slightly updated version of the previous patch I posted. It's based on a newer release (20041119). Changes are described in the top of the diff. If there are no regressions, this will be the patch that gets committed. Mark [1] http://www.santcroos.net/mark/freebsd/files/acpi_import_20041119.diff.gz -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 24 22:19:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C622416A4CE for ; Wed, 24 Nov 2004 22:19:22 +0000 (GMT) Received: from admin.cablespeed.com (mail.admin.cablespeed.com [216.15.205.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 471A443D48 for ; Wed, 24 Nov 2004 22:19:22 +0000 (GMT) (envelope-from rschi@rsmba.biz) Received: from [66.235.37.251] (account schilling@cablespeed.com HELO rsmba.biz) by admin.cablespeed.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 78198562 for freebsd-acpi@freebsd.org; Wed, 24 Nov 2004 16:19:21 -0600 Message-ID: <41A509BB.7000500@rsmba.biz> Date: Wed, 24 Nov 2004 14:22:51 -0800 From: Richard Schilling Organization: Richard Schilling, MBA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040412 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Thinkpad 600x ACPI issues with Linksys PCM100 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2004 22:19:22 -0000 Discovered some issues when trying to run the Thinkpad 600x with a PCM100 PCMCIA network card. Disabling ACPI completely is the only workaround I can come up with so far. The laptop (battery?) gets hot. I get temperature warnings. When running the laptop with a PCM 200 PCMCIA network card I get the same. Interrupts don't seem to be handled well. The PCM100 driver (ed0) reports a device timeout. The lights turn on and the interface is recognized though. Attached is a copy of my dmesg -a output, and the output from acpidump -t. ========================== acpidump output /* RSD PTR: OEM=IBM, ACPI_Rev=1.0x (0) RSDT=0x0bfd0000, cksum=161 */ /* RSDT: Length=44, Revision=1, Checksum=58, OEMID=IBM, OEM Table ID=TP600X, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 Entries={ 0x0bfd0100, 0x0bfd0040 } */ /* FADT: FACS=0xbfdf000, DSDT=0xbfd0200 INT_MODEL=PIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0xa0, ACPI_DISABLE=0xa1, S4BIOS_REQ=0xa2 PSTATE_CNT=0x0 PM1a_EVT_BLK=0xef00-0xef03 PM1a_CNT_BLK=0xef04-0xef05 PM2_CNT_BLK=0x22-0x22 PM_TMR_BLK=0xef08-0xef0b GPE0_BLK=0xef0c-0xef0f P_LVL2_LAT=1 us, P_LVL3_LAT=65 us FLUSH_SIZE=32768, FLUSH_STRIDE=32 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=13, MON_ALRM=0, CENTURY=50 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,P_LVL2_UP,SLP_BUTTON,RTC_S4,DCK_CAP} */ /* FACS: Length=64, HwSig=0x00000028, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=43145, Revision=1, Checksum=119, OEMID=IBM, OEM Table ID=TP600X, OEM Revision=0x28, Creator ID=MSFT, Creator Revision=0x100000c */ /* BOOT: Length=40, Revision=1, Checksum=101, OEMID=IBM, OEM Table ID=TP600X, OEM Revision=0x1, Creator ID=, Creator Revision=0x0 */ ============================= dmesg -a output Copyright (c) 1992-2004 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 5.2.1-RELEASE #0: Wed Nov 24 02:10:02 GMT 2004 root@:/usr/obj/usr/src/sys/COGNITION Preloaded elf kernel "/boot/kernel/kernel" at 0xc095d000. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc095d21c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc095d2c8. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (498.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 201129984 (191 MB) avail memory = 185724928 (177 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00f9d70 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xef08-0xef0b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 2 INTA routed to irq 3 via \\_SB_.LNKA pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 2 INTB routed to irq 3 via \\_SB_.LNKB pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 3 INTA routed to irq 3 via \\_SB_.LNKC pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 6 INTA routed to irq 3 via \\_SB_.LNKA pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 7 INTD routed to irq 3 via \\_SB_.LNKD agp0: mem 0x40000000-0x43ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib1: slot 0 INTA routed to irq 3 via \\_SB_.LNKA pci1: at device 0.0 (no driver attached) cbb0: mem 0x50103000-0x50103fff irq 3 at device 2.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb1: mem 0x50102000-0x50102fff irq 3 at device 2.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] pci0: at device 3.0 (no driver attached) pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0x4000-0x401f irq 3 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 drq 3 on acpi0 sio0: type 8250 or not responding atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_ec0: port 0x66,0x62 on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 sio1: configured irq 4 not in bitmap of probed irqs 0 sio1: port may not be enabled orm0: